# Password reset switches application context on shared tenant with custom domain **URL:** \ **Category:** Get Help\ **Tags:** reset-password-prompt-new-experience, login-experience\ **Created:** [January 26, 2026, 12:13pm UTC](https://community.auth0.com/t/password-reset-switches-application-context-on-shared-tenant-with-custom-domain/196602 "2026-01-26T12:13:56Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![robert.gerace](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/robert.gerace/32/78175_2.png) [@robert.gerace](https://community.auth0.com/u/robert.gerace)\ **Post date:** [January 26, 2026, 12:13pm UTC](https://community.auth0.com/t/password-reset-switches-application-context-on-shared-tenant-with-custom-domain/196602/1 "2026-01-26T12:13:56Z")
I have a single Auth0 tenant with two separate applications: - **App A (UAT)** - for our staging environment at [uat.example.com](http://uat.example.com) - **App B (Production)** - for our production environment at [app.example.com](http://app.example.com) Both applications use the same custom domain (e.g., [auth.example.com](http://auth.example.com)). **The Problem:** When a user initiates a password reset from the production application: 1. They start at [app.example.com](http://app.example.com) → redirected to [auth.example.com/authorize?client\_id=](http://auth.example.com/authorize?client_id=)[prod-client-id]… 2. On the Universal Login page, the footer correctly shows “Back to App B” (production) 3. User clicks “Forgot Password” and receives the reset email 4. User clicks the reset link, changes their password successfully 5. **After the password change, the page footer now shows “App A” (UAT)** 6. User is redirected to [uat.example.com](http://uat.example.com) instead of [app.example.com](http://app.example.com) The application context is switching from production to UAT somewhere during the password reset flow, even though the initial request clearly used the production client\_id. **What I’ve Verified:** - Production app’s Allowed Callback URLs, Logout URLs, and Web Origins only reference [app.example.com](http://app.example.com) - UAT app’s URLs only reference [uat.example.com](http://uat.example.com) - Application Login URI on production is correctly set - Email templates are configured for production - Tried passing client\_id explicitly when creating password change tickets via Management API - same result - All environment variables in production servers are correct **Question:** Has anyone experienced this issue where the password reset flow switches application context on a shared tenant? Is there something in how Auth0 handles password reset that defaults to the first application or ignores the originating client\_id? Any insight would be appreciated. I’ve also opened a support ticket but wanted to check if others have encountered this. * * * ---
**Author:** ![vlad.murarasu](https://sea1.discourse-cdn.com/auth0/user_avatar/community.auth0.com/vlad.murarasu/32/72793_2.png) [@vlad.murarasu](https://community.auth0.com/u/vlad.murarasu)\ **Post date:** [January 26, 2026, 3:21pm UTC](https://community.auth0.com/t/password-reset-switches-application-context-on-shared-tenant-with-custom-domain/196602/3 "2026-01-26T15:21:07Z")
Hi @robert.gerace, Welcome to the Auth0 Community! The issue typically occurs because the password reset ticket loses its association with the original `client_id` during the transition between the login page and the reset email. Even if the initial `/authorize` request has the correct `client_id`, the Change Password email template must be explicitly configured to forward that context back to the reset success page. The most likely culprit in your case is that the **Redirect To** field in your **Change Password** email template is either blank or pointing to a static URL. If it’s blank, Auth0 sometimes falls back to the “first” application it finds or the Tenant-level default, which explains why your users are landing on the UAT app footer. Typically, environments should be created in separate tenants rather than in separate apps within the same tenant, since all apps in a tenant share the same connections and user pools. This will completely solve the problem much more easily and **is the official way to set up multiple environments**. You can check our official docs for more details on how to set them up: > **[Set Up Multiple Environments - Auth0 Docs](https://auth0.com/docs/get-started/auth0-overview/create-tenants/set-up-multiple-environments)** > > Describes how to use multiple Auth0 tenants to manage various environments. **Although it is recommended that you set up multiple tenants** , if you don’t want to, if you want to keep using the same tenant, you can ensure the `client_id` is dynamically handled in your email template and that each application knows where to “return” to. ### 1. Set the Application Login URI Ensure **both** applications have the **Application Login URI** field populated (not just the Callback URLs). - Go to **Applications \> Applications \> [Your App] \> Settings**. - Locate **Application Login URI**. - For App B (Prod), set it to: `https://app.example.com/login` (or your specific login route). - For App A (UAT), set it to: `https://uat.example.com/login`. ### 2. Update the Change Password Email Template You must ensure the email link includes the `client_id` from the originating request. - Navigate to **Branding \> Email Templates** and select **Change Password**. - In the **Redirect To** field, use the following Liquid syntax: `{{ application.callback_domain }}` or specifically handle the client: ```html {% if client_id == 'PROD_CLIENT_ID' %} https://app.example.com/login {% else %} https://uat.example.com/login {% endif %} ``` - **Crucial Step:** Ensure the **URL Lifetime** is sufficient and the **Redirect To** field is actually used. If you are using the Management API to create tickets, ensure you explicitly pass the `result_url` parameter. ### 3. Verification of the Link Check the link inside the actual email received by the user. It should look something like: `https://auth.example.com/lo/reset?ticket=...#` If you append `&client_id=[PROD_ID]` to your Management API ticket generation call, Auth0 uses that `client_id` to look up the correct branding and “Back to” link for the success page. We still, however, encourage you to set up multiple tenants. If you have any further questions, please don’t hesitate to reach out. Have a good one, Vlad ---
**Author:** ![system](https://global.discourse-cdn.com/auth0/original/3X/b/5/b560f266932fcce5d57f09a6595bd50518cae3f3.jpeg) [@system](https://community.auth0.com/u/system)\ **Post date:** [February 9, 2026, 3:22pm UTC](https://community.auth0.com/t/password-reset-switches-application-context-on-shared-tenant-with-custom-domain/196602/4 "2026-02-09T15:22:06Z")
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.