[Bug]: Entra sign-in hides passkeys in the preview browser because the User-Agent contains Electron/ #30014

Area: apps/desktop

Steps to reproduce

1. Open the desktop app on Windows 11 (tested on T3 Code Beta 0.1.6, Electron 44.10.0 / Chromium 152) with a passkey provider that works in the browser (Windows Hello, or 1Password as Windows plugin passkey provider).
2. Open a preview tab on https://login.microsoftonline.com/ (for example through any Entra-protected app) and enter a work account that has a passkey registered.
3. Look at the sign-in options after the username step.

Expected behavior

Entra offers the passkey / security key option, as it does in Chrome and Edge. WebAuthn itself works in the preview browser: PublicKeyCredential.isUserVerifyingPlatformAuthenticatorAvailable() is true, and passkeys work on webauthn.io.

Actual behavior

Entra does not offer the passkey option. Only the Authenticator and password options are shown.

Evidence (A/B test, same build, same machine, same account)

Dev build of this repo (signed Electron copy, own --home-dir), navigator.userAgent:

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) T3CodeDev/44.10.0 Chrome/152.0.7977.169 Electron/44.10.0 Safari/537.36

navigator.userAgent in the page is identical in both runs; only the request header differs. Installed Beta 0.1.6 (T3CodeBeta/0.1.6 … Electron/44.10.0) behaves like the first row.

Not verified: I did not capture the header on the wire, and I do not know whether Electron/ is the only trigger or whether the app token also matters. The conclusion comes from the behavior change after the rewrite and from the code path below.

An earlier measurement in another Electron app showed the same pattern: with an Edge User-Agent, Entra's IsFidoSupported flipped from 0 to 1.

Why this is separate from the existing UA decisions

BrowserSession.ts deliberately keeps Electron's native User-Agent because rewriting it breaks Cloudflare Turnstile (#7110). A global rewrite is therefore not an option. #22444 (WhatsApp Web) is the same kind of site-specific UA problem.

Suggested direction, which I will open as a small PR if this is acceptable: rewrite only the User-Agent request header, only for the Microsoft sign-in hosts (login.microsoftonline.com, login.microsoft.com, login.live.com), and only by removing the Electron/<version> token. navigator.userAgent and every other site stay untouched.

Impact

Major degradation for Entra-protected sign-ins in the preview browser: users with passkey-only or passkey-preferred accounts cannot use them.

Version or commit

Installed: T3 Code Beta 0.1.6. Source checked: main (apps/desktop/src/preview/BrowserSession.ts).

Environment

Windows 11 Pro 10.0.26200, Electron 44.10.0, Chromium 152.0.7977.169, 1Password as Windows plugin passkey provider (the dev build had to be Authenticode-signed for the provider to show up; that is a separate matter).

Workaround

None in the installed app. In a dev build, the header rewrite described above makes the passkey option appear.

Related

• In-app browser: passkeys stored on a phone (cross-device / QR) never prompt #14398 (cross-device passkeys in the in-app browser)
• fix(desktop): keep the native preview User-Agent so Turnstile passes #7110 (why the native UA is kept)
• [Bug]: WhatsApp Web rejects the integrated browser despite Chromium 152 #22444 (site-specific UA problem for WhatsApp Web)
• Microsoft Q&A asking whether Entra intentionally hides passkeys for Electron/ User-Agents: https://learn.microsoft.com/en-us/answers/questions/6059339/entra-sign-in-does-not-offer-passkeys-when-the-use