Feature Request: Application-Specific "Back to Login" URIs for Password Reset Flow

Get Help
,
1

We are currently navigating a challenge with the password reset flow that likely affects many enterprise clients managing multi-platform ecosystems (e.g., Web and Mobile).

We have a shared Auth0 tenant serving both a Web application and a Mobile app. Currently, the “Back to Login” button at the end of the password reset flow is enabled via the “Tenant Login URI” in the Advanced Settings.

Since the “Tenant Login URI” is a single global setting, it cannot distinguish between different client_ids.

  1. When a mobile user completes a password reset, they click “Back to Login.”

  2. The browser redirects them to the Web application’s login route (the global URI).

  3. This triggers a new login transaction with the Web app’s client_id.

  4. Even upon a successful login, the user encounters an invalid state error. This happens because the OIDC state parameter initiated by the mobile app does not match the session context of the web app’s redirect.

We considered using a deep link to the mobile app’s /login route as the “Tenant Login URI,” but this creates a poor user experience as the browser window closes and re-opens abruptly.

It would be ideal if the “Back to Login” button behaved like the “Back to {tenant name}” button found on the “Forgot Password” prompt—maintaining the context of the original application. Specifically, allowing for an Application-level Login URI or a way to dynamically resolve the return path based on the client_id that initiated the flow would resolve this state conflict.

2

Hi!

It certainly sounds like there could be a feature request here but perhaps you could overwrite this with ACUL?

1 Like
3

Don’t think so, even if we did have that page as ACUL page, the issue is that the ‘start’ of the login process should be ‘started’ from the same device it ‘ends’.

4

Are you able to dynamically change the return URI? And then add both of them as allowed callbacks.

1 Like
6

yes, but it still won’t work (tried it). The state that is created when the user initiates the auth transaction ends up being different if you effectively re-start the process from another client, which leads to an invalid state error once the final callback is routed to.

1 Like
7

Hi @eidriahnluca

Welcome to the Auth0 Community!

Reading through your use case, I believe there are some changes that you can apply or try out, which should yield the desired flow. Allow me to share some documentations that go over some implementations on this matter:

If these do not match your desired flow, I warmly recommend submitting this Feature Request in our dedicated section for Product Feedback, which is being monitored by the Product Team. Others can vote on your idea and more votes can help expedite it’s development.

Hope this helped!
Gerald