# Feature Request: Application-Specific "Back to Login" URIs for Password Reset Flow **URL:** \ **Category:** Get Help\ **Tags:** reset-password-prompt-new-experience, login-experience\ **Created:** [March 10, 2026, 11:02am UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989 "2026-03-10T11:02:21Z")\ **Posts on this page:** 11\ **Page:** 1
**Author:** ![eidriahnluca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/eidriahnluca/32/78626_2.png) [@eidriahnluca](https://community.auth0.com/u/eidriahnluca)\ **Post date:** [March 10, 2026, 11:02am UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/1 "2026-03-10T11:02:21Z")
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_id`s. 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. ---
**Author:** ![JFoxUK](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/jfoxuk/32/78058_2.png) [@JFoxUK](https://community.auth0.com/u/JFoxUK)\ **Post date:** [March 10, 2026, 11:16am UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/2 "2026-03-10T11:16:13Z")
Hi! It certainly sounds like there could be a feature request here but perhaps you could overwrite this with ACUL? ---
**Author:** ![eidriahnluca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/eidriahnluca/32/78626_2.png) [@eidriahnluca](https://community.auth0.com/u/eidriahnluca)\ **Post date:** [March 10, 2026, 12:54pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/3 "2026-03-10T12:54:33Z")
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’. ---
**Author:** ![JFoxUK](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/jfoxuk/32/78058_2.png) [@JFoxUK](https://community.auth0.com/u/JFoxUK)\ **Post date:** [March 10, 2026, 1:56pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/4 "2026-03-10T13:56:29Z")
Are you able to dynamically change the return URI? And then add both of them as allowed callbacks. ---
**Author:** ![eidriahnluca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/eidriahnluca/32/78626_2.png) [@eidriahnluca](https://community.auth0.com/u/eidriahnluca)\ **Post date:** [March 10, 2026, 2:54pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/6 "2026-03-10T14:54:20Z")
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. ---
**Author:** ![gerald.czifra](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/gerald.czifra/32/75301_2.png) [@gerald.czifra](https://community.auth0.com/u/gerald.czifra)\ **Post date:** [March 10, 2026, 6:03pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/7 "2026-03-10T18:03:37Z")
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: - [Conditionally Redirect Users After a Password Reset in New Universal Login](https://support.auth0.com/center/s/article/How-to-conditionally-redirect-users-from-a-password-reset), which takes advantage of the [password-reset-post-challenge trigger](https://auth0.com/docs/customize/actions/explore-triggers/password-reset-triggers/post-challenge-trigger/post-challenge-api-object); - [Help me with redirect to login after password change](https://community.auth0.com/t/help-me-with-redirect-to-login-after-password-change/192763); - [Password Change Redirect Behavior](https://support.auth0.com/center/s/article/Classic-Login-which-redirect-url-setting-is-picked-up-on-password-change). If these do not match your desired flow, I warmly recommend submitting this Feature Request in our dedicated section for [Product Feedback](https://community.auth0.com/c/feedback/95), 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 ---
**Author:** ![eidriahnluca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/eidriahnluca/32/78626_2.png) [@eidriahnluca](https://community.auth0.com/u/eidriahnluca)\ **Post date:** [March 11, 2026, 3:53pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/8 "2026-03-11T15:53:38Z")
@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. ---
**Author:** ![JFoxUK](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/jfoxuk/32/78058_2.png) [@JFoxUK](https://community.auth0.com/u/JFoxUK)\ **Post date:** [March 11, 2026, 3:55pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/9 "2026-03-11T15:55:32Z")
Why are your native apps using the browser window to perform the transaction? ---
**Author:** ![eidriahnluca](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/eidriahnluca/32/78626_2.png) [@eidriahnluca](https://community.auth0.com/u/eidriahnluca)\ **Post date:** [March 11, 2026, 3:58pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/10 "2026-03-11T15:58:47Z")
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. ---
**Author:** ![JFoxUK](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/jfoxuk/32/78058_2.png) [@JFoxUK](https://community.auth0.com/u/JFoxUK)\ **Post date:** [March 11, 2026, 4:08pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/11 "2026-03-11T16:08:06Z")
Your alternative but not recommended could be embedded - [Embedded Login - Auth0 Docs](https://auth0.com/docs/authenticate/login/embedded-login) ---
**Author:** ![system](https://global.discourse-cdn.com/auth0/original/3X/b/5/b560f266932fcce5d57f09a6595bd50518cae3f3.jpeg) [@system](https://community.auth0.com/u/system)\ **Post date:** [March 25, 2026, 4:08pm UTC](https://community.auth0.com/t/feature-request-application-specific-back-to-login-uris-for-password-reset-flow/197989/12 "2026-03-25T16:08:10Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.