[Android] Custom Domain + prompt: 'login': entering a different user's credentials redirects to Application Login URI in the same Custom Tab instead of invoking the callback

[fariabu]

Summary

On Android, with a Custom Domain configured and customScheme: 'https' (i.e. relying on Android App Links / Universal Links for the callback, not a custom URL scheme like myapp://), calling authorize() a second time with additionalParameters: { prompt: 'login' } while a session for User A is already active forces a fresh hosted login screen, as expected.

• If the credentials entered on that screen belong to the same user (User A) that already has an active session, authorize() completes normally: the callback is invoked and the promise resolves with fresh credentials.
• If the credentials entered belong to a different user (User B), the Custom Tab does not dismiss or close — it stays open, but the webview inside it navigates away from the auth flow and redirects, in that same Custom Tab, to the Application's Login URI configured in the Auth0 Dashboard. The callback URL is never hit, and authorize() never resolves or rejects.

Reproduction steps

1. Tenant has a Custom Domain configured (CNAME, not *.auth0.com), with assetlinks.json served for Android App Links verification.
2. Call authorize() with customScheme: 'https' and no prompt param → log in as userA@example.com → resolves fine, session established.
3. While that session is active, call authorize() again with customScheme: 'https' and additionalParameters: { prompt: 'login' }.
4. The hosted login page opens again (Custom Tab).
   5a. Enter credentials for the same user userA@example.com and submit → ✅ works, callback invoked, authorize() resolves.
   5b. Instead, enter credentials for a different, existing user userB@example.com and submit → 🐛 the same Custom Tab (webview) stays open but redirects to the dashboard's configured Application Login URI instead of hitting the callback — it does not close. authorize() hangs — never settles.

Expected behavior

authorize() should complete the same way regardless of whether the submitted credentials match the previously-authenticated user — i.e. redirect to the app's HTTPS callback URL (App Link) and resolve with fresh credentials for User B.

Dummy code

import Auth0, { useAuth0 } from 'react-native-auth0';

const auth0 = new Auth0({
  domain: 'auth.example.com', // Custom Domain (CNAME), not *.auth0.com
  clientId: 'YOUR_CLIENT_ID',
});

function useReauth() {
  const { authorize } = useAuth0();

  // Step 1: normal login as User A — works fine.
  async function login() {
    return authorize(
      { scope: 'openid profile email' },
      // customScheme: 'https' -> SDK builds the HTTPS App Link callback
      // itself instead of using a custom URL scheme redirect.
      { customScheme: 'https' }
    );
  }

  // Step 2: forced re-auth while User A's session is active.
  //  - Same user (User A) submitted on the form -> works fine.
  //  - Different user (User B) submitted on the form -> bug below.
  async function reauthenticate() {
    try {
      const credentials = await authorize(
        {
          scope: 'openid profile email',
          additionalParameters: { prompt: 'login' },
        },
        { customScheme: 'https' }
      );
      // Expected: resolves with fresh credentials, for whichever user logs in.
      return credentials;
    } catch (e) {
      // 🐛 Never reached on Android when User B logs in on the form.
      // The same Custom Tab stays open but navigates to the Dashboard's
      // Application Login URI instead of the callback, and this promise
      // just never settles.
      console.log('authorize() error', e);
    }
  }

  return { login, reauthenticate };
}

Environment

• react-native-auth0: 5.11.0
• react-native: 0.79.7
• Android: compileSdkVersion/targetSdkVersion 36, minSdkVersion 29
• Custom Domain: Yes
• Redirect: customScheme: 'https' (Android App Links / HTTPS Universal Link callback, not a custom URL scheme)
• Platform: Android only reproduces; iOS not affected

[fariabu]

@subhankarmaiti ☝️

[subhankarmaiti]

Thanks for the detailed report.

I couldn't reproduce this on the latest SDK — Custom Domain, customScheme: 'https' App Link callback, second authorize() with prompt: 'login', different user's credentials on the hosted page. It resolves every time for me.

Landing on the Application Login URI is what Auth0 does when the login transaction behind the state parameter can't be resumed, same as a bookmarked or expired login page (docs). So the browser never gets the callback URL, and the SDK waits on a redirect that never comes. The transaction is also tied to the browser session, and on Classic Universal Login re-authenticating as a different user in the same session can invalidate the one in flight, which fits same-user re-auth working while a user switch doesn't.

Could you tell me:

• New Universal Login (/u/login) or Classic? Database connection or social/enterprise?
• Which URL do you land on — the app's Login URI or a tenant-level default login route?
• Does it still happen with a custom scheme callback instead of customScheme: 'https'?