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.
When a mobile user completes a password reset, they click “Back to Login.”
The browser redirects them to the Web application’s login route (the global URI).
This triggers a new login transaction with the Web app’s client_id.
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.
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’.
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.
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.
@gerald.czifra the first link you’ve shared is useful, but we’ve already achieved this functionality. The issue with this approach comes from native mobile apps that open a browser window to perform the transaction.
When such users perform a password reset, they get to the “Back to log in” button on the final page. There they click on that button which on mobile redirects them to a ‘deeplink’ within the app. In such a case the browser window closes, and if the deeplink is configured correctly, re-opens. This is not perfect UX for our org. I will open a Feature Request for this.
I meant the in-app browser, a web view component.
This way authentication is handled by auth0 and we don’t have to maintain it every time changes are made to the auth flow.