When using password authentication is it possible to send an verification email to the registered user? Right now I am using the Stytch node.js package, but when creating a user from the login in form through the SDK it creates is with an unverified email address without sending a verification email to the user. Is there a setting I am missing or is there another way to make this work?
Hey Kevin – thanks for posting!
You can use either our headless Email Magic Links send/ login or create methods or our Email OTP send/ login or create methods to verify a user’s email address right after they’ve signed up with an email address + password (and are still logged into your application).
Once your user completes either the Email Magic Links or Email OTP flow, their email address will be marked as verified. Just as a reminder, you’ll first need to enable whichever authentication flow you choose via the Frontend SDKs tab in the Stytch Dashboard.
Please let me know if you have any questions about this, and I’ll be happy to help!
Hi Nicole,
Thanks for the response, while the magic link flow works, this does cause a password reset trigger for the new user, which is definitely a downside for usability and user friendliness. It would be great if Stytch could allow a feature to enable a simple email verification option which doesn’t require OTP’s or cause the user to require to reset their password.
For now I will just implement my own email verification flow outside of Stytch and just use Stytch for basic user auth and keep everything else in my own code as that seems to be the best option for my application atm.
Hey Kevin – so sorry about that, I misread “node.js” as “next.js” and gave you instructions for our frontend JavaScript SDK rather than our backend Node SDK. My apologies!
If you’re using our backend Node SDK, you’ll need to include either the session_token or session_jwt produced by your call to the Create user by password endpoint in your calls to the above Send endpoint and the corresponding Authenticate endpoint (either Authenticate magic link or Authenticate one-time passcode).
This will make it so that a password reset won’t be required after email verification, which (as you discovered) we do otherwise require if a Passwords user authenticates via a passwordless option for the first time in order to prevent an account takeover attack vector (see here for additional information).
Using the above strategy, you should be able to implement the user experience you’re looking for. Please let me know if you have any questions about this, and I apologize again for the confusion!
Hi Nicole,
Not sure if I fully understand this solution. When I checked the “Create User by Password” endpoint it doesn’t return a session token. How I have implemented the flow so far:
Registration:
- User uses registration form and posts the info to the backend (express Node.js)
- Backend calls the create user with password endpoint and return user id
- Backend stores user ID locally for application purposes
- Backend calls the Authenticate user with password call with the registration information and receives a Session and JWT token
- Backend calls the Magic Link send email endpoint to verify the email with the session token
- Backend redirects user to verify email information and without setting the session since email is not yet verified
Email verification:
- User receives email with magic link
- Backend receives call back with the magic link token in the query parameters
- Backend calls Magiclinks Authenticate with this token (no session included)
- Backend now knows email is verified and returns the session token from the authenticate call
- User is logged in, but has to reset email if logged out
Do you mean that in the second part of my flow I should keep that initial Session token (from part 1) stored in my DB or set as a session with the user to attach it to the magiclinks authenticate call?
I guess setting the session after registration would work as I need to check for email verified anyway as I don’t want unverified users on my app. If that is what I am doing wrong I will go and test changing that flow now. As that would solve the issue.
It would still be nice if there was an option in the Create user with password endpoint to set an option to send a verification email upon that create, or are there other reasons I am not thinking of that might make that difficult to implement?
Hi Nicole,
That was the solution, thank you for the help. I added the session token after the registration, so I could easily attach it to the email callback and then used that to verify the email, now all I have to do is implement a verified user check in the authentication flow so unverified users get redirected even if they have a session token.
I will say for this app I was considering a few auth providers. Auth0 and Stytch, I had some different issues with Auth0 causing me grief trying to locally store a userID after creation as using their main selling point(for me) the prebuilt branded UI. It was a right pain to figure out and when I used their help forums I got 0 responses nor was I able to find a nice workable work around out of the box. The fact Stytch actually responds in these forums and has an active user Slack group where I found part of this solution really makes the difference for me. With this solved I have my complete auth flow for my app resolved and I can get to building the actual app. So it seems Stytch will be the auth provider for my app! Thanks again for all the help, amazing support experience!
Hey Kevin,
Thanks so much for the kind words! We really appreciate that, and are very happy to hear that you’ve chosen to go with Stytch – welcome aboard! 
I just have one note about the flow you outlined: if you include a session_duration_minutes parameter in your passwords.create request, you should receive a session token in the passwords.create response. That way, you can just use that session token instead of making a separate call to passwords.authenticate.
Regarding your suggestion to offer an email verification option directly from the Create user with password endpoint – I think that’s a great idea, and I’ll record it internally as a feature request! Even though this flow can be accomplished using a combination of Stytch endpoints, I think it’s definitely common enough for us to consider adding a more streamlined way to go about it in the future.
Thanks again for the positive feedback – always happy to help out with any other questions that come up going forward!
-Nicole