Forogt password flow leads to dead end (even with login URI set)

When a user clicks “Forgot Password” from the Universal Login screen, they are able to reset their password but then reach the following screen:


This is a confusing dead end that makes it hard for the user to get back to the app.

When we initiate a password reset email from the management API, the flow correctly ends with a button to return to the app:

This are many posts about this issue (see here, here), but the typical solution does not work for us.

We have already configured the “Application Login URI” as detailed in the documentation (and this guide). For both of our applications, it is set to a valid (https, non-localhost) url with a domain included in the allowed web origins. I’ve set this both through the dashboard UI and the management API using the exact cURL command provided in the docs, so it should definitely be set correctly.

The other different between the universal login initiated vs API initiated flows is that the flow initiated from the universal login uses OTP verification, while the flow from the API request uses a reset link. I suspect this has something to do with why the universal login flow is missing the “back to application” link, though I’m not sure why. Note that we are using the “Identifier First” login flow with OTP for email verification.

Is there any way to fix this and display a “back to application” link on the forgot password flow? Is this a bug in the OTP flow on Auth0’s end, or is there some secret setting we missed somewhere?

Hi @ashwsn,

Welcome to the Auth0 Community!

This Community article discusses the password change redirect behavior: Password Change Redirect Behavior

Could you give that a review? It may be that you need to also set a Tenant Login URI depending on how the flow initiates.

Best,

Mary Beth

Hi @marybeth.hunter , thanks for the reply.

We have already tried setting the Tenant Login URI as well and that does not change the behavior, there is still no redirect. This wouldn’t be a great solution for us even if it did work, as we have multiple separate apps and no single login page that would work for all of them.

I’ve read the “Password Change Redirect Behavior” article, and it does not seem to include the case that we have an issue with. They cover password resets via the management API or via email link, but not via email OTP which is the flow we having the issue with. And regardless, all the relevant fields mentioned on that page are set correctly.

To clarify the full flow we have issues with, it is as follows:

  1. User clicks sign in button on a specific application
    • This uses the loginWithRedirect function from the auth0-react library
    • Client id and redirect URI are set correctly. The regular sign in flow works as expected and returns the user to the correct app
    • url is https://<domain>/u/login/identifier?state=<state>
  2. User enters their email, clicks “Continue”
    • url is https://<domain>/u/login/password?state=<state>
  3. User clicks “Forgot password?”
    • url is https://<domain>/u/reset-password/request/Username-Password-Authentication?state=<state>
  4. User clicks “Continue”
    • url is https://<domain>/u/email-identifier/challenge?state=<state>
  5. User enters 6 digit code from email, clicks “Continue”
    • url is https://<domain>/u/reset-password/change?state=<state>
  6. User enters new password, clicks “Reset password”
  7. “Password Changed!” screen is shown, with no redirect link

As mentioned before, the redirect link is shown for the separate flow initiated via the management API that uses an email link instead of OTP, which confirms that the Login URI is set correctly. Additionally, the email template for the OTP code is receiving the correct application variable, so the client ID must be set correctly.

As far as I can tell this must be a bug on Auth0’s end specific to the OTP password reset flow. We have done everything right according to every piece of documentation and community post I’ve found.

Hi @ashwsn,

Thank you for all of this information! Please allow me some time to review it and I will get back to you as soon as I can!

Thanks,

Mary Beth

Hi @ashwsn,

Thank you for your patience while we were out for the holidays! I have reached out internally to confirm what the expected behavior is for this flow using the OTP password reset flow. I will update you when I hear back!

Thanks,

Mary Beth

Hi @ashwsn,

The team asked me to create an Engineering ticket about this issue. I have just submitted that to the team, and I will keep you updated with their findings.

Thanks,

Mary Beth

Hi @ashwsn,

Engineering has created a backlog item to address this, and the fix will be addressed prior to the OTP verification features going General Availability.

Thanks for bringing this to our attention!

Best,

Mary Beth

Hi @marybeth.hunter , thanks for your help with this!

1 Like