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?
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:
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>
User enters their email, clicks “Continue”
url is https://<domain>/u/login/password?state=<state>
User clicks “Forgot password?”
url is https://<domain>/u/reset-password/request/Username-Password-Authentication?state=<state>
User clicks “Continue”
url is https://<domain>/u/email-identifier/challenge?state=<state>
User enters 6 digit code from email, clicks “Continue”
url is https://<domain>/u/reset-password/change?state=<state>
User enters new password, clicks “Reset password”
“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.
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!
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.
Engineering has created a backlog item to address this, and the fix will be addressed prior to the OTP verification features going General Availability.
