[$250] [Mobile] Okta SSO requires double login after idle timeout — app freezes on SAML session handoff

[MelvinBot]

If you found this issue via BugZero, please follow the BugZero triage guidelines in the wiki article here. In particular:

• Populate the Version Number field (you can find this in the App Deployer or GitHub Releases) and change the template title.
• If the bug is a result of a regression, label with Regression and add the Original Author - @<author> and Regression Author - @<author> labels after determining the source of the regression (you can use git bisect).
• If unable to reproduce the bug, consider labeling with Needs Investigation and tagging relevant engineers.

---

Action Performed:

1. Log into Expensify mobile app via Okta SSO
2. Leave app idle for ~3–4 hours (aligned with Okta global session idle timeout)
3. Return to app
4. Complete Okta re-authentication + MFA in the in-app browser
5. Tap "Done" on in-app browser to return to the app

Expected Result:
User is successfully authenticated and returned to the app with a persisted session — no additional login required.

Actual Result:
App freezes briefly after returning from the in-app browser, then logs the user out and redirects to the Expensify login screen. User must log in a second time (including Okta MFA). The second login works as expected.

Workaround:
User can log in a second time — the second attempt always succeeds.

Platforms:
Which of our officially supported platforms is this issue occurring on?

• iOS
• Android
• Desktop
• Web
• Mobile Web (Chrome)
• Mobile Web (Safari)

Version Number: Latest (reported on 9.3.39-3+ and still occurring)

Reproducible in staging?: Unknown

Logs: N/A

Notes/Photos/Videos:

Additional Context

• Affected domain: Pontera USA (policyID: A5C281D064505B6B)
• Auth method: Okta SSO (SAML)
• Okta session policy: Max session 8 hours, idle timeout 4 hours
• Scope: Affects all mobile app users in this organization; NOT reproducible on desktop
• Behavior is unique to Expensify — not occurring with other Okta-integrated mobile apps (Gmail, Slack, Zoom)

Technical Context from Investigation on Expensify/Expensify#613615

The mobile SAML re-authentication flow relies on a multi-redirect chain that passes a 1-minute shortLivedAuthToken back to the app via a Universal Link / deep link. When the app is backgrounded or in a transitional state during this handoff, the token can expire or the deep link can fail to fire, causing the first login attempt to silently fail.

Several server-side fixes have already been merged (Auth #19751, Web-Expensify #50652) addressing samlInfiniteMobileSessions flag preservation. However, the client-side handling of the SAML deep link callback when the app is resuming from a backgrounded state needs investigation — this is likely where the mobile-specific failure occurs.

Key areas to investigate in the App:

• How does the React Native app handle receiving a SAML deep link callback (isSAML=true) when it has an expired session?
• Is there a race condition between the in-app browser closing and the deep link being processed?
• Does the app correctly handle the shortLivedAuthToken exchange when resuming from background?

Upstream issue: https://github.com/Expensify/Expensify/issues/613615

Issue Owner

Current Issue Owner: @bernhardoj

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~022038834681163684626
• Upwork Job ID: 2038834681163684626
• Last Price Increase: 2026-03-31

[MelvinBot]

Proposal

What is the root cause of that problem?

When a mobile SAML/Okta user returns from the in-app browser (after completing MFA), a race condition occurs between two competing flows:

1. AppState "became active" listener — fires immediately when the app resumes from the background and triggers reconnectApp() using the OLD expired authToken (NetworkConnection.ts:322-328, AuthScreensInitHandler.tsx:75-103)
2. SAML callback — openAuthSessionAsync promise resolves with the new shortLivedAuthToken and calls signInWithShortLivedAuthToken() (SAMLSignInPage/index.native.tsx:57-61)

If Path 1 fires before Path 2's optimistic Onyx update sets isAuthenticatingWithShortLivedToken=true, the sequence is:

• reconnectApp() gets a 407 (NOT_AUTHENTICATED) from the server
• Reauthentication middleware tries to re-authenticate with stored auto-generated credentials
• For SAML users, these credentials may be empty/invalid (they signed in via SAML, not password)
• Reauthentication fails → redirectToSignIn() → Onyx.clear() wipes ALL data including any newly set authToken (Authentication.ts:178-194, SignInRedirect.ts:84-118)
• AuthScreens unmounts → cleanupSession() → HttpUtils.cancelPendingRequests() cancels any in-flight signInWithShortLivedAuthToken request (Session/index.ts:1008-1023)

The second login always works because the app is in a clean state with no competing reconnection callbacks.

Supporting evidence: Authentication.ts:133-140 has the "redirect to sign-in for missing credentials" logic commented out with a reference to #fireroom-2026-01-28-user-signout, confirming this exact pattern was already suspected.

This is mobile-only because: (a) the in-app browser backgrounds the app, triggering AppState callbacks on resume, and (b) desktop doesn't use openAuthSessionAsync.

What changes do you think we should make in order to solve the problem?

In SAMLSignInPage/index.native.tsx, set isAuthenticatingWithShortLivedToken=true in Onyx before opening the in-app browser (i.e., before the openAuthSessionAsync call). This blocks the reauthentication middleware from racing against the SAML callback. Reset the flag to false if the browser is cancelled or fails.

This ensures that when the app returns to the active state and reconnectApp() fires with the expired token, any resulting 407 response will hit the isAuthenticatingWithShortLivedToken guard in Authentication.ts:110-117 and abort reauthentication instead of triggering redirectToSignIn.

What alternative solutions did you explore? (Optional)

1. Suppress reconnection callbacks during SAML flow — Unregister the NetworkConnection reconnection listener before opening the in-app browser and re-register after. This is more invasive and could miss legitimate reconnection events if the network was actually lost.

2. Add retry logic in the SAML callback error path — Currently if the guard !account?.isLoading && credentials?.login && shortLivedAuthToken fails at SAMLSignInPage/index.native.tsx:57, the flow falls through to clearSignInData() which logs the user out. Adding a retry here would be a workaround rather than fixing the root race condition.

3. Delay the AppState "became active" reconnection callback — Add a debounce or short delay before firing reconnectApp() to give the SAML callback time to set its guard flag. This is fragile and timing-dependent.

---

Next Steps for Contributor+ team: Reply with @MelvinBot implement this to create a draft PR, @MelvinBot <your feedback> to refine this analysis, or explain why you are rejecting Melvin's proposal.

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @bernhardoj (External)

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~022038834681163684626

[trasnake87]

Proposal

Please re-state the problem that we are trying to solve in this issue.

After an Okta SSO idle timeout on mobile, completing SAML re-authentication in the in-app browser causes the app to freeze and then log the user out, forcing a redundant second login. The second attempt always succeeds.

What is the root cause of that problem?

When the app resumes from background with an expired SAML session, the Reauthentication middleware in src/libs/Middleware/Reauthentication.ts#L96 unconditionally calls reauthenticate() for any 407 response. For SAML users, this cascades into Authenticate() in Authentication.ts which fails at requireParameters (because SAML users have no stored autoGeneratedLogin/autoGeneratedPassword), and the catch block fires redirectToSignIn() → Onyx.clear(). This Onyx.clear() is destructive — it wipes all app data including any new session being established by the concurrent SAML re-authentication callback from openAuthSessionAsync. The middleware has no awareness that the current user is a SAML user who cannot reauthenticate with stored credentials, so it always attempts the doomed reauthentication path.

What changes do you think we should make in order to solve the problem?

We should add a SAML-awareness check in src/libs/Middleware/Reauthentication.ts so that when a 407 is received for a SAML user, we skip the full reauthenticate() flow (which destructively calls Onyx.clear()) and instead just invalidate the auth tokens, letting React's navigation naturally redirect to sign-in:

// Add at module level in Reauthentication.ts
import Onyx from 'react-native-onyx';
import ONYXKEYS from '@src/ONYXKEYS';

let signedInWithSAML = false;
Onyx.connectWithoutView({
    key: ONYXKEYS.SESSION,
    callback: (val) => { signedInWithSAML = !!val?.signedInWithSAML; },
});

// Insert before line 96 (`return reauthenticate(...)`)
if (signedInWithSAML) {
    // SAML users cannot reauthenticate with stored credentials.
    // Clear only auth tokens (not full Onyx.clear) to avoid destroying
    // a concurrent SAML re-auth session from the in-app browser callback.
    Onyx.merge(ONYXKEYS.SESSION, {authToken: null, encryptedAuthToken: null});
    setIsAuthenticating(false);
    if (isFromSequentialQueue) {
        return data;
    }
    if (request.resolve) {
        request.resolve(data);
    }
    return data;
}

This avoids the destructive Onyx.clear() for SAML users while still properly invalidating the expired session, allowing the SAML re-authentication flow to complete without interference. The subsequent openApp() call after successful SAML login will refresh all stale data.

[trasnake87]

Contributor details
Your Expensify account email: trasnake87@gmail.com
Upwork Profile Link: https://www.upwork.com/freelancers/~010f770315ab181656

[melvin-bot]

✅ Contributor details stored successfully. Thank you for contributing to Expensify!

[wildan-m]

Proposal

Please re-state the problem that we are trying to solve in this issue.

On mobile, when a SAML/Okta SSO user returns to the app after an idle timeout and completes re-authentication + MFA in the in-app browser, the app freezes briefly, logs the user out, and forces a second login. The second login always succeeds.

What is the root cause of that problem?

When the in-app browser closes and the app resumes from a backgrounded state, two competing paths fire concurrently:

Path 1 — App resume reconnection: AppStateMonitor.addBecameActiveListener (registered by listenForReconnect()) fires immediately when the app transitions from background/inactive → active. This triggers triggerReconnectionCallbacks, which calls reconnectApp() with the old expired authToken:

App/src/libs/NetworkConnection.ts

Lines 322 to 328 in 2b517db

	function listenForReconnect() {
	Log.info('[NetworkConnection] listenForReconnect called');
	AppStateMonitor.addBecameActiveListener(() => {
	triggerReconnectionCallbacks('app became active');
	});
	}

App/src/libs/Navigation/AppNavigator/AuthScreensInitHandler.tsx

Lines 102 to 103 in 2b517db

	NetworkConnection.listenForReconnect();
	NetworkConnection.onReconnect(() => handleNetworkReconnect());

Path 2 — SAML callback: The openAuthSessionAsync promise resolves with the redirect URL containing the new shortLivedAuthToken, and handleNavigationStateChange calls signInWithShortLivedAuthToken():

App/src/pages/signin/SAMLSignInPage/index.native.tsx

Lines 57 to 61 in 2b517db

	if (!account?.isLoading && credentials?.login && shortLivedAuthToken) {
	Log.info('SAMLSignInPage - Successfully received shortLivedAuthToken. Signing in...');
	signInWithShortLivedAuthToken(shortLivedAuthToken, true);
	return;
	}

The reauthenticate() function has an existing guard that checks isAuthenticatingWithShortLivedToken and aborts if true:

App/src/libs/Authentication.ts

Lines 110 to 117 in 2b517db

	// Prevent re-authentication if authentication with shortLiveToken is in progress
	if (isAuthenticatingWithShortLivedToken) {
	Log.hmmm('[Reauthenticate] Authentication with shortLivedToken is in progress. Re-authentication aborted.', {
	command,
	isSupportAuthTokenUsed,
	});
	return Promise.resolve(false);
	}

However, this flag is only set inside signInWithShortLivedAuthToken()'s optimistic data (via getShortLivedLoginParams at line 171), which runs after the browser returns — too late to block the Path 1 reauthentication that fires simultaneously on app resume.

App/src/libs/actions/Session/index.ts

Lines 154 to 175 in 2b517db

	function getShortLivedLoginParams(isSupportAuthTokenUsed = false, isSAML = false) {
	const optimisticData: Array<OnyxUpdate<typeof ONYXKEYS.ACCOUNT | typeof ONYXKEYS.SESSION | typeof ONYXKEYS.HYBRID_APP>> = [
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.ACCOUNT,
	value: {
	...CONST.DEFAULT_ACCOUNT_DATA,
	isLoading: true,
	},
	},
	// We are making a temporary modification to 'signedInWithShortLivedAuthToken' to ensure that 'App.openApp' will be called at least once
	{
	onyxMethod: Onyx.METHOD.MERGE,
	key: ONYXKEYS.SESSION,
	value: {
	signedInWithShortLivedAuthToken: true,
	signedInWithSAML: isSAML,
	isAuthenticatingWithShortLivedToken: true,
	isSupportAuthTokenUsed,
	},
	},
	];

If Path 1's reauthenticate() runs before Path 2 sets the guard, it proceeds with auto-generated credentials. For SAML users whose IdP session has expired server-side, this authentication fails — triggering redirectToSignIn() which calls Onyx.clear(), wiping all session state (including any in-flight SAML authentication) and cancelling pending requests via cleanupSession():

App/src/libs/actions/SignInRedirect.ts

Lines 84 to 105 in 2b517db

	return Onyx.clear(keysToPreserve).then(() => {
	if (CONFIG.IS_HYBRID_APP) {
	resetSignInFlow();
	HybridAppModule.signOutFromOldDot();
	}
	clearAllPolicies();
	// When logging out from imported state, reset shouldForceOffline to false and clear the imported state flag
	// so the user can log back in
	if (currentIsUsingImportedState) {
	Onyx.merge(ONYXKEYS.NETWORK, {shouldForceOffline: false});
	Onyx.merge(ONYXKEYS.IS_USING_IMPORTED_STATE, false);
	}
	if (!errorMessage) {
	return;
	}
	// `Onyx.clear` reinitializes the Onyx instance with initial values so use `Onyx.merge` instead of `Onyx.set`
	Onyx.merge(ONYXKEYS.SESSION, {errors: getMicroSecondOnyxErrorWithMessage(errorMessage)});
	});
	}

App/src/libs/actions/Session/index.ts

Lines 1008 to 1023 in 2b517db

	function cleanupSession() {
	Pusher.disconnect();
	Timers.clearAll();
	Welcome.resetAllChecks();
	MainQueue.clear();
	HttpUtils.cancelPendingRequests();
	PersistedRequests.clear();
	NetworkConnection.clearReconnectionCallbacks();
	SessionUtils.resetDidUserLogInDuringSession();
	resetNavigationState();
	clearCache().then(() => {
	Log.info('Cleared all cache data', true, {}, true);
	});
	clearCachedAttachments();
	clearSoundAssetsCache();
	}

This is mobile-only because: (a) openAuthSessionAsync backgrounds the app on Android and puts it inactive on iOS, triggering AppState callbacks on resume, and (b) desktop uses a different SAML implementation that doesn't use the in-app browser.

The second login always works because the app is in a clean state with no competing reconnection flow — the AppStateMonitor.becameActive listener has already fired for that app resume cycle.

What changes do you think we should make in order to solve the problem?

In SAMLSignInPage/index.native.tsx, set isAuthenticatingWithShortLivedToken to true in Onyx before calling openAuthSessionAsync. This ensures the guard in reauthenticate() is active for the entire duration of the SAML browser session, blocking any reconnection-triggered reauthentication from racing with the SAML callback.

Reset the flag to false on all non-success exit paths:

• If the browser is cancelled (response.type !== 'success')
• If the browser throws an error
• If handleNavigationStateChange falls through (condition at line 57 fails)

When signInWithShortLivedAuthToken() is called on the success path, its own optimistic data takes over flag management (sets true optimistically, resets in finallyData), so no manual reset is needed there.

What alternative solutions did you explore? (Optional)

1. Add a synchronous setter in Authentication.ts instead of using Onyx merge — directly setting the module-level isAuthenticatingWithShortLivedToken variable. This would avoid any theoretical async propagation delay from Onyx.merge → connectWithoutView callback. However, since the Onyx merge happens before openAuthSessionAsync (before the app backgrounds for seconds/minutes), the callback has ample time to propagate. The additional complexity of a synchronous setter is not warranted.

2. Uncomment the credentials guard in Authentication.ts:133-140 — the code that redirects to sign-in when autoGeneratedLogin/autoGeneratedPassword are missing is currently commented out (investigating #fireroom-2026-01-28-user-signout). Uncommenting it would make reauthentication fail faster for SAML users without stored credentials, but it doesn't address the core race condition and could reintroduce the user-signout issue being investigated.

Compare branch: https://github.com/Expensify/App/compare/main...wildan-m:App:wildan/86705-saml-sso-double-login?expand=1

[wildan-m]

Proposal

Updated

Added compare branch with implementation.

[Abubakar-01]

Report - Okta SSO requires double login after idle timeout — app freezes on SAML session handoff

Please re-state the problem that we are trying to solve in this issue.
After an Okta SSO session times out (~4 hours idle), mobile users who successfully complete Okta re-authentication and MFA in the in-app browser are silently logged out and redirected to the login screen instead of being returned to the app. The second login attempt always succeeds. This affects all mobile users on SAML/Okta SSO and is not reproducible on desktop.
What is the root cause of that problem?
There are two compounding issues in the client-side SAML callback handling:
Primary : stale account.isLoading gate in SAMLSignInPage.tsx: handleNavigationStateChange only calls signInWithShortLivedAuthToken if !account?.isLoading && credentials?.login && shortLivedAuthToken are all truthy. When a session expires, Onyx sets account.isLoading = true as part of the session cleanup. By the time the Okta callback fires with a fresh shortLivedAuthToken, account.isLoading is still true from the prior session teardown so the condition fails, falls through to clearSignInData(), and the user is logged out.
Secondary : getLastShortAuthToken() guard in LogInWithShortLivedAuthTokenPage.tsx: This guard exists to prevent replaying stale deep links, but it can incorrectly block a legitimate re-authentication if the newly issued token matches the cached last token. When it fires, it silently returns without signing in.

What changes do you think we should make in order to solve the problem?

App/src/pages/signin/SAMLSignInPage/index.native.tsx

Line 71 in b078372

[credentials?.login, account?.isLoading, translate],

[translate],

App/src/pages/signin/SAMLSignInPage/index.native.tsx

Line 57 in 57c1582

if (!account?.isLoading && credentials?.login && shortLivedAuthToken) {

if (shortLivedAuthToken) {

App/src/pages/LogInWithShortLivedAuthTokenPage.tsx

Line 44 in b078372

if (token && !account?.isLoading) {

if (token) {

App/src/pages/signin/SAMLSignInPage/index.native.tsx

Line 21 in 57c1582

const [account] = useOnyx(ONYXKEYS.ACCOUNT);

(Remove this line)

App/src/pages/LogInWithShortLivedAuthTokenPage.tsx

Line 33 in b078372

if (!account?.isLoading && authTokenType === CONST.AUTH_TOKEN_TYPES.SUPPORT) {

if (authTokenType === CONST.AUTH_TOKEN_TYPES.SUPPORT) {

App/src/libs/actions/Session/index.ts

Line 987 in b078372

}

NetworkStore.setLastShortAuthToken(''); }

What alternative solutions did you explore?

N/A