@User the overall approach is as follows: - The email verification logic depends on a session being created. So by the time the email verification screen is shown a session must already exist. - For social login, the flow is not modified since there is no password step involved. - For email password login, you need to send a "fake" password to the backend and also modify the form to not show the password field. Both of these can be done via JS manipulation of the form (i'll show this in the demo app) - When the backend gets this fake password, it will create a user + a session as usual. - In order to protect your app, you need to mark this session as "unusable" somehow (by setting some flag in the access token) and make your APIs such that it checks if this flag is set or not - if not, only then the API should continue. You also need to modify the sign in logic + does email exist logic + to check if the email being sent to them is associated with this fake pass, and if it is, then treat it as if the email doesn't exist (This step can be tricky, but i'll show this in the demo app as well) - Post email verification, you want to show the form again, but this time without the social providers and the email field. Just the password. In here, when the user submits the password, you want to modify the user's existing "fake" password to the one they set, and change the session to remove that flag which marks it as unusable. - Post that, you want to show your own screen for collecting user meta data. If the above doesn't make too much sense right now (cause this perhaps needs a full length blog posts.. haha) - i'll showcase this in the demo app. But I posted this here just in case.