Login: Keep the mTLS certificate when handling the OAuth redirect

[paolostivanin]

Problem

Re-authentication fails with "Malformed server configuration" on the login screen when the server requires a client certificate. Fresh login is unaffected, which is what makes this confusing. The account is then left unusable and reinstalling the app is the only way out.

Reproduced against a host behind Cloudflare mTLS, but it applies to any mTLS-protected instance.

Root cause

When Android kills the app process while the OAuth Custom Tab is in the foreground, the browser redirect is handled by a brand new LoginActivity (isTaskRoot == true) rather than being forwarded to a live one via onNewIntent.

That redirect intent carries no extras, so loginAction fell back to ACTION_CREATE and userAccount was null. restoreClientCertAlias() ran before restoreAuthState(), so it took the "fresh login, no certificate" branch and set clientManager.loginClientCertAlias = null. The recovery /status.php request therefore went out with no client certificate and the server answered with an HTML 403.

StatusRequester.handleRequestResult parsed the body as JSON before looking at the status code, so the resulting JSONException was mapped to INSTANCE_NOT_CONFIGURED, surfacing as "Malformed server configuration" instead of the real HTTP error. The status-code branch below it was effectively dead code for any non-JSON body (proxy error pages, captive portals, empty bodies).

Why it needed a reinstall

getServerInfoIsError only printed the message. It left pendingAuthorizationIntent armed with a now-dead single-use authorization code (so retrying produced a misleading "Unsuccessful authorization"), never called clearAuthState(), and left the url field empty. If the user then logged in fresh from that same screen, loginIsSuccess wrote KEY_MTLS_CERT_ALIAS = null onto the account, breaking every subsequent connection.

Changes

LoginActivity

• Restore the persisted auth state at the top of onCreate on the redirect leg, before anything downstream reads loginAction or userAccount.
• Key restoreClientCertAlias() on userAccount rather than loginAction. Every launch that passes EXTRA_ACCOUNT also passes a non-CREATE EXTRA_ACTION, so this is behaviour-preserving for the existing paths and only changes the recovered-redirect case.
• Only overwrite the stored alias in loginIsSuccess when the user actually picked or removed a certificate on this screen (new clientCertAliasChangedByUser flag, persisted across configuration changes).
• On a failed server check during the redirect leg, drop the dead authorization code, clear the auth state and refill the url field so the screen stays recoverable.
• Report a 403 during login as a possible client certificate problem instead of the generic "Permission error", which is useless in this context.

StatusRequester / GetRemoteStatusOperation

• Check the HTTP status before parsing the body as JSON.
• Stop dereferencing result.data.baseUrl unconditionally: data is only set on success, so every failed status check turned into an opaque NPE result instead of the actual HTTP error.

The fix covers the whole recovery chain, not just /status.php: OIDC discovery, the token exchange and client registration all go through ClientManager.getClientForAnonymousCredentials, which applies loginClientCertAlias on both the new-client and reuse branches.

Tests

New StatusRequesterHandleResultTest (5 cases) guards the regression:

Response	Expected
403 + HTML mTLS rejection page	FORBIDDEN, httpCode 403
502 + HTML	UNHANDLED_HTTP_CODE, httpCode 502
401 + empty body	UNAUTHORIZED
200 + installed:false	INSTANCE_NOT_CONFIGURED
200 + installed:true	OK_SSL, base url preserved

assembleOriginalDebug builds and the app, domain, data and library unit test suites pass.

[guruz]

Ouch, I need to have a look at this.
This introduced quite some complexity...

FYI: detekt fail ^

[paolostivanin]

thanks, fixed 😄

[guruz]

I tested the non-cert login and also re-auth case, still seems to work.

[guruz]

@paolostivanin Trying with https://client.badssl.com/ (see https://badssl.com) shows the warning triangle and "unknown error" in wizard. Was that supposed to show something better?

08-11 13:57:22.650  7527  7546 E GetInstancesViaWebFingerOperation: Failed requesting WebFinger info
08-11 13:57:22.652  7527  7546 D (GetInstancesViaWebFingerOperation.kt:67): E: Failed requesting WebFinger info
08-11 13:57:22.653  7527  7546 E GetInstancesViaWebFingerOperation: *** status code: 400; response message: <html>
08-11 13:57:22.653  7527  7546 E GetInstancesViaWebFingerOperation: <head><title>400 No required SSL certificate was sent</title></head>
08-11 13:57:22.653  7527  7546 E GetInstancesViaWebFingerOperation: <body bgcolor="white">
08-11 13:57:22.653  7527  7546 E GetInstancesViaWebFingerOperation: <center><h1>400 Bad Request</h1></center>
08-11 13:57:22.653  7527  7546 E GetInstancesViaWebFingerOperation: <center>No required SSL certificate was sent</center>
08-11 13:57:22.653  7527  7546 E GetInstancesViaWebFingerOperation: <hr><center>nginx/1.10.3 (Ubuntu)</center>
08-11 13:57:22.653  7527  7546 E GetInstancesViaWebFingerOperation: </body>
08-11 13:57:22.653  7527  7546 E GetInstancesViaWebFingerOperation: </html>

[paolostivanin]

Basically, from time to time I get "token expired, login again" and when I do that after I've "allowed" the app after login , I am redirected to the app's main page where it url is shown and I get a "malformed server configuration" and I can't go forward with the login.
I need to clear data and login again for it work.

With this change now the re-login process works fine when behind mtls.

[guruz]

@paolostivanin I understand this :) I just meant if it was supposed to show a better/different error message for https://client.badssl.com/

Your version:

[guruz]

Current main:

[guruz]

Your version:

The "unknown error" is a worse message than "Malformed server configuration" for this specific server.
Maybe there is a simple way to improve this.. if not let me know, we can merge for now anyway