Hi, I currently have a setup where I’m enforcing verified email on login. I want the registration flow to be frictionless for the user, meaning that I want the user to do the following: registration flow -> verification flow -> automatically logged in. The problem is that the closest you can get is: having these 2 hooks after registration flow:

show_verification_ui

,

session

. The problem with this setup is that even if you don’t verify the email you are logged in, which is not what I want. Does anyone know a workaround?

@bright-action-91775 I’m facing the same issue. We have two options: 1. Remove the session hook after registration, but that complicates the flow into: registration → verification → login. 2. Keep the existing flow, but restrict all app access until the email is verified. Most users will follow the intended flow anyway and won’t back out of the verification step. There’s also a related problem with email updates: When a user changes their email, Ory immediately switches it, and the new email becomes unverified. This means the user is now logged in with an unverified email even though we require verified emails. And if the user mistypes the new email, the account effectively becomes locked - they can’t log in because unverified logins are disabled, and they can’t recover the account because the mistyped email isn’t theirs.

@steep-greece-67535 I guess I will handle limits on the application

Its very bad that this is not handled well, but it is what it is…

Hey both, I think here are the options you have 1. Strict but more steps - Registration → redirected to verification UI. - User verifies. - User then logs in (now passes require_verified_address). This is the only way to guarantee there is never a valid session with an unverified email after registration. Security-first: remove session after registration and accept registration → verification → login. 2. Keep auto‑login, but lock app until verified - keep session after registration, plus show_verification_ui. - require_verified_address on login Then, in your app: - On every request / page load, check session.identity.verifiable_addresses for a verified: true address. If none are verified, treat the user as “restricted”: - redirect them to your verification screen or - show a banner and block sensitive actions until verification is done. UX-first: keep session and enforce “verified-only” behavior in your app by checking the session’s verification status. --- I would recommend option 2 if you need frictionless registration but strong enforcement of verification later. For the “email change → unverified → locked account” scenario, you can: - Enable show_verification_ui after settings/profile, so changing the email immediately forces verification UI instead of just showing a success message. - In your app, again gate access based on the verified status until the new email is verified. Let me know what you think.

Hi @magnificent-energy-493, thanks for the reply. Obviously these are the only valid approaches for now, I’m thinking what if you make session hook available also after verification flow, isn’t it what is currently already happening on recovery flow?

@magnificent-energy-493 Are there any alternative approaches for handling email updates? Even with that implementation, a user can still get locked out. Redirecting them to the verification URL (which I already do) doesn’t guarantee they’ll complete the verification — they might just close the page. Then, when they try to log in again, they’ll get an error telling them to verify the new email. But if they mistyped that email, there’s no way for them to go back and fix it.

what if you make session hook available also after verification flow, isn’t it what is currently already happening on recovery flow?

yea that could probably be an improvement for this use case 🤔 we do have plans to improve the verification flow, basically rewrite it from the top. its been designed with a few use cases in mind years ago, but since we learned that there are many more edge cases to verification. unfortunately it's quite complex overall and we need to do it in a backwards compatible way, so no concrete timeline can be shared atm.

That is actually a good idea, I didn’t thought that way. I know that I tried to manually do email updates completely (like sending email from my backend validating it there and then updating it through admin API) but I got some issue with the identity update, like it wasn’t allowing setting email to verified through API or something like that, it was couple months ago so I don’t remember it. Thank you for idea, I will try it today to see if there are any issues on that, if not, then I will go with it.