Password reset switches application context on shared tenant with custom domain

Get Help
,
1

I have a single Auth0 tenant with two separate applications:

Both applications use the same custom domain (e.g., auth.example.com).

The Problem:

When a user initiates a password reset from the production application:

  1. They start at app.example.com → redirected to 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 instead of 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

  • UAT app’s URLs only reference 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.

3

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:

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:
{% 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