fetchAuthenticationConfiguration dynamically re-enables browser login, no way to force it off

[caff-uk]

Description

SalesforceSDKManager.setBrowserLoginEnabled() is called by fetchAuthenticationConfiguration() when the SDK detects a My Domain org with SSO enabled. This dynamically re-enables browser login even when the app has explicitly disabled it, causing a login loop for apps that must use WebView-only authentication.

In SDK 13.x, setBrowserLoginEnabled was made internal, so apps cannot call it from Java at all. But the SDK itself still calls it internally via fetchAuthenticationConfiguration(), overriding the app's intent.

Root Cause

In SalesforceSDKManager.kt, fetchAuthenticationConfiguration() calls setBrowserLoginEnabled(true, ...) when it detects the org supports browser-based auth. There is no mechanism for the app to indicate "never enable browser login regardless of server configuration."

Apps that block browser OAuth callbacks (e.g., because the Connected App doesn't support custom callback URL schemes) get stuck in a loop: the SDK enables browser login → Chrome Custom Tab opens → callback is blocked → login fails → repeat.

Steps to Reproduce

1. Configure a Connected App that does not support browser-based OAuth callback URLs
2. Block browser OAuth callbacks in a custom LoginActivity subclass
3. Log in to a My Domain org with SSO enabled
4. SDK detects SSO, calls fetchAuthenticationConfiguration(), enables browser login
5. Next login attempt routes through Chrome Custom Tab instead of in-app WebView
6. Callback is blocked → login loop

Expected Behavior

The SDK should provide a way to force-disable browser login so that fetchAuthenticationConfiguration() cannot re-enable it. For example:

var isBrowserLoginForcedOff = false

@Synchronized
fun setBrowserLoginEnabled(browserLoginEnabled: Boolean, shareBrowserSessionEnabled: Boolean) {
    if (isBrowserLoginForcedOff && browserLoginEnabled) return
    isBrowserLoginEnabled = browserLoginEnabled
    // ...
}

Apps could then set SalesforceSDKManager.getInstance().isBrowserLoginForcedOff = true in MainApplication and be confident browser login stays disabled.

Additionally, setBrowserLoginEnabled should be public (not internal) so apps can manage this themselves. (Note: SDK 13.2.1 added "Login for Admin" which may have changed visibility — but the force-off mechanism is still missing.)

Affected Versions

• Confirmed on 13.2.0 and 13.2.1
• Affects any app using WebView-only authentication on SSO-enabled orgs

Environment

• Android SDK 13.2.0/13.2.1
• Connected App without browser OAuth callback URL support
• My Domain orgs with SSO/identity provider enabled

[wmathurin]

Thank you for the clear write-up, @caff-uk! You're right that fetchAuthenticationConfiguration unconditionally overrides any prior setting with no first-class opt-out. We've logged a bug and will add a proper isBrowserLoginForcedOff mechanism in an upcoming release. In the meantime, overriding the isBrowserLoginEnabled property setter in your SalesforceSDKManager subclass is a functional workaround.

[caff-uk]

Thanks @wmathurin !

[brandonpage]

Hi @caff-uk, this is intentional and not a bug. The Mobile SDK has always respected the org side configuration for browser based authentication (which defaults to off). If it is enabled there we will use it. Furthermore, this ask is actually the opposite direction of where we are headed. Mobile SDK 14.0 will default to Advanced Authentication for all servers with an a flag to opt out that will be removed in 15.0. We are doing this because it will eventually be required by the server for the overwhelming majority of users (if not all).

Is there a specific reason why you cannot use Advanced Authentication?