Advanced auth: no ephemeral browser-session option on Android (iOS parity gap) — prompt=login doesn't prevent session reuse for SAML/WS-Fed federated IdPs, breaking user switching on shared devices

[caff-uk]

Description

On Android, advanced authentication (browser Custom Tab) relies on appending &prompt=login to the authorize URL "to prevent the browser cookie from bypassing login if it exists" (LoginActivity.buildCustomTabAuthorizeUrl). For orgs whose My Domain is federated to an external IdP via SAML 2.0 / WS-Fed (e.g. Microsoft Entra), prompt=login on the Salesforce authorize URL is not propagated to the external IdP as a forced re-authentication. The IdP's persistent browser SSO session therefore silently re-authenticates the previously signed-in user.

Impact: on shared devices (e.g. retail store tablets shared by staff), a user cannot switch to or add a different account. switchToNewUser() opens the Custom Tab, the IdP session re-asserts the previous user, and the app returns to that same user — getAuthenticatedUsers() never changes. This makes multi-user / shared-device usage unworkable on federated orgs.

The iOS SDK avoids this by running the advanced-auth browser session ephemerally by default (SalesforceSDKManager.useEphemeralSessionForAdvancedAuth = YES → ASWebAuthenticationSession.prefersEphemeralWebBrowserSession = YES), so no persistent IdP session is ever visible to reuse — regardless of federation. The Android SDK has no equivalent option.

Root Cause

Android's only mechanism to avoid session reuse is the prompt=login query parameter, appended in LoginActivity.buildCustomTabAuthorizeUrl (libs/SalesforceSDK/src/com/salesforce/androidsdk/ui/LoginActivity.kt):

val urlWithSdkInfo = "$loginUrl&sdkInfo=$sdkInfo&auth_trigger=$authTrigger"
return if (sharedBrowserSession) urlWithSdkInfo else urlWithSdkInfo + PROMPT_LOGIN
// private const val PROMPT_LOGIN = "&prompt=login"

prompt=login is honored at the Salesforce /authorize endpoint, but for a My Domain federated via SAML/WS-Fed, Salesforce does not translate it into ForceAuthn on the AuthnRequest to the external IdP. The external IdP's live browser session is therefore reused, and the same user is silently re-asserted.

The Custom Tab itself is built without an isolated/ephemeral session in LoginActivity.loadLoginPageInCustomTab:

val customTabsIntent = CustomTabsIntent.Builder().apply {
    ...
    setShareState(CustomTabsIntent.SHARE_STATE_OFF)
    ...
    // no ephemeral / cookie-isolated session
}.build()

By contrast, iOS (SFOAuthCoordinator.m) applies an ephemeral session that is on by default (SalesforceSDKManager.m: self.useEphemeralSessionForAdvancedAuth = YES;):

_asWebAuthenticationSession.prefersEphemeralWebBrowserSession =
    [SalesforceSDKManager sharedManager].useEphemeralSessionForAdvancedAuth;

Steps to Reproduce

1. Configure an org whose My Domain is federated to an external IdP via SAML 2.0 (e.g. Microsoft Entra), with the IdP keeping a persistent browser session ("stay signed in").
2. On an Android device, sign in as User A via advanced auth (Custom Tab).
3. Call UserAccountManager.switchToNewUser() (or use the account switcher's "add new user").
4. At the IdP, the persistent session silently re-authenticates User A — no account chooser is shown.
5. Observe: the app returns to User A; getAuthenticatedUsers() still contains only User A. Switching to a different user is impossible without manually clearing the external browser's cookies (which the app cannot do).

Expected Behavior

The advanced-auth browser session should be able to run ephemerally (cookie-isolated), matching iOS, so that a persistent external-IdP session cannot silently bypass account selection. This would let users switch/add accounts on shared devices regardless of federation.

Suggested Fix

androidx.browser 1.8.0+ exposes CustomTabsIntent.Builder.setEphemeralBrowsingEnabled(true) (honored by Chrome 136+, feature-detectable via CustomTabsClient.isEphemeralBrowsingSupported()). Add an ephemeral option on SalesforceSDKManager (mirroring iOS useEphemeralSessionForAdvancedAuth) and apply it in loadLoginPageInCustomTab:

// SalesforceSDKManager.kt — mirrors iOS useEphemeralSessionForAdvancedAuth
var useEphemeralSessionForAdvancedAuth = true

// LoginActivity.loadLoginPageInCustomTab
val customTabsIntent = CustomTabsIntent.Builder().apply {
    ...
    if (SalesforceSDKManager.getInstance().useEphemeralSessionForAdvancedAuth) {
        setEphemeralBrowsingEnabled(true)
    }
}.build()

We have verified this one-line change resolves shared-device user switching on a SAML/Entra-federated org (Chrome 136+).

Open question: on iOS this is on by default — is there a reason it isn't the Android default? If default-on is undesirable on Android (e.g. because ephemeral browsing is browser-version dependent and disables autofill of saved credentials), exposing it as an opt-in setter would still close the parity gap.

Affected Versions

• Confirmed on 14.0.0-rc.2 (the prompt=login mechanism is also present in rc.0/rc.1).
• Affects orgs federated to an external IdP via SAML 2.0 / WS-Fed, on shared / multi-user devices.

Environment

• Android SDK 14.0.0-rc.2
• Advanced authentication (browser Custom Tab, web-server + PKCE)
• My Domain federated to Microsoft Entra via SAML 2.0
• Custom Tab served by Chrome 136+ (where ephemeral browsing is available)

[caff-uk]

One more thing we'd appreciate guidance on: we would prefer not to fork/patch the SDK to carry this change. Until an ephemeral option can be added, is there a supported way to make shared-device user switching work on a SAML/WS-Fed–federated org without modifying SDK source?

Specifically:

• Is there an existing hook to customize the login CustomTabsIntent before it is launched? We only found SalesforceSDKManager.customTabBrowser (which selects the browser package, not the session behavior), and LoginActivity.loadLoginPageInCustomTab is internal, so an app subclass of LoginActivity can't override it.
• Is SalesforceSDKManager.loginViewModelFactory (or another public seam) a viable place for an app to influence the advanced-auth Custom Tab / force an isolated session?
• Is there a recommended pattern for shared-device account switching on federated (SAML) orgs that we've missed?

Thanks!

[brandonpage]

Hi @caff-uk,

We are very late in the 14.0 release cycle, but I will discuss using CustomTabsIntent.Builder.setEphemeralBrowsingEnabled with the team.

Personally the ephemeral browsing setting feels a bit like a bandaid solution. prompt=login is an OIDC standard and should be respected by all servers involved. My understanding is that the server does pass that parameter to the IdP when we send it. If you believe that they do not, a server side investigation should be opened through the standard channels. If the IdP is not respecting the parameter then that needs to be fixed on their end. The proper fix is server side, but we are not opposed to adding the option at some point.

[caff-uk]

Thanks @brandonpage — appreciate you raising it with the team.

On the "bandaid vs proper fix" point, I wanted to flag a closed iOS issue that seems directly relevant: forcedotcom/SalesforceMobileSDK-iOS#3856 ("SSO with Microsoft Entra"). There, @wmathurin documents the ephemeral session as the first-class, supported control over exactly this Entra interaction:

By default, the SDK sets prefersEphemeralWebBrowserSession = YES … This isolates the Salesforce login session from all other browser sessions on the device — including any Microsoft Entra session … As a result, when the Salesforce SSO flow redirects to Microsoft Entra, the Entra session cookies aren't visible and the user is prompted to re-authenticate.

So on iOS the behavior is directly toggleable:

• useEphemeralSessionForAdvancedAuth = YES (default) → Entra session isolated → user is prompted (this is exactly what we need for shared-device switching).
• = NO → shared Safari session → Entra session reused silently.

Android has no equivalent to either state — the login Custom Tab is effectively always in the "= NO" (shared session) mode, so on our SAML→Entra org the persistent Entra session is silently reused and the previous user is re-asserted, with no app-side way to force the isolated/prompt behavior iOS gets by default.

This is also why prompt=login doesn't resolve it for us in practice: with the shared (non-ephemeral) session, the Entra IdP session cookie is present and satisfies the SAML SSO, so the same user is asserted regardless. We're happy to also pursue the server-side angle (confirming whether SF emits ForceAuthn on the SAML AuthnRequest for federated My Domains, and whether Entra honors it) — but given #3856, the ephemeral option looks less like a bandaid and more like restoring parity with a control iOS already ships and documents as the fix for the identical scenario.

Would exposing useEphemeralSessionForAdvancedAuth on Android (even opt-in, default off to preserve current behavior) be a reasonable parity addition? We verified setEphemeralBrowsingEnabled(true) resolves our case on Chrome 136+.

[wmathurin]

Thanks @caff-uk. We closed the gap with #3052.
It is part of the just released 14.0.0-rc.3.

[caff-uk]

Thank you @wmathurin and @brandonpage for the quick turnaround here, I really appreciate the help! This has solved a major issue for us. Have a great weekend!