Chrome 145 turns several FedCM compatibility changes into requirements. The larger decision is architectural: where browser-mediated sign-in should lead, where the existing federation path must remain, and what the dialog does not consent to.
The immediate deadline is narrow. Chrome 143 introduced several FedCM changes with a transition window through versions 143 and 144; Chrome 145 enforces the incompatible parts. If an identity provider uses the affected metadata, nonce, or error paths, it needs an update. But a compatibility patch is not yet a rollout strategy.
For a multi-domain SaaS provider, the useful question is not “Can we add FedCM?” It is “Which sign-in journeys should the browser mediate, and what happens when it cannot?” Chrome’s own guidance says FedCM is not supported in every browser and relying parties should retain their existing non-FedCM federation solution. The fallback is part of the design, not cleanup for later.
- Relying-party domain: requests identity credentials for one configured IdP.
- Browser UI: controls account presentation and the FedCM sign-in prompt.
- Identity provider: serves configuration, accounts, metadata, assertion, and login endpoints.
- Application session: receives the FedCM response through the product’s existing sign-in path before creating a local session.
- Fallback branch: unsupported, disabled, dismissed, or failed FedCM returns the user to the existing federation or account-recovery path.
Who is actually inside the adoption boundary?
FedCM is a browser-mediated identity federation API that does not rely on third-party cookies or navigational redirects. According to Chrome’s FedCM overview, it is useful when an identity provider has third-party relying parties, owns an identity solution used across multiple domains, or wants federation to keep working when third-party cookies are unavailable. The same guide recommends FedCM when RPs are third-party or when more than four RPs use the identity solution.
That makes an IdP-backed SaaS family a credible candidate, not every product domain an automatic launch target. Inventory the relying parties first: origin, client identifier, fallback path, account population, regulatory region, session policy, and owner. A forgotten staging client or acquired domain is an identity boundary, not an administrative footnote.
Does FedCM replace the current OAuth or OIDC system?
No. FedCM is protocol-agnostic and can sit above an existing federation service. Chrome describes exchanging the response from FedCM for an OAuth access token as one possible design. Treat the browser step as a credential-delivery lane and keep the rest of the existing federation path unless a separately documented migration changes it. FedCM’s browser UI does not define the application’s complete session architecture.
Chrome’s 2026 identity guidance recommends FedCM to IdPs because the interaction is handled through browser UI. That browser mediation is the point. Do not recreate the same account chooser beneath it, and do not treat a successful credential request as permission for unrelated personalization, advertising, or data sharing.
Which UI mode belongs on a SaaS sign-in page?
FedCM exposes passive and active modes. Passive mode can present a prompt without a user gesture, subject to browser state: the person must be signed in to a supported IdP, must not be in a cooldown state, and must not have disabled FedCM. Active mode requires transient user activation, such as selecting a “Sign in with” control. Chrome currently limits active mode to one identity provider in the request.
Use that constraint as product guidance. An explicit account-access page usually has a clear active trigger and room for a visible fallback. Passive mode can support a lower-friction return journey, but the browser decides whether the prompt appears. A product flow that becomes blank when passive UI is suppressed has confused an enhancement with navigation.
What exactly changes at Chrome 145?
| Area | Chrome 143–144 status | Chrome 145 requirement | Failure-state handling |
|---|---|---|---|
| Client metadata validation | Old and new forms accepted during transition | When using client_metadata, publish the required endpoint information in /.well-known/web-identity; Chrome enforces accounts_endpoint |
Validate every production IdP configuration URL before rollout |
| Nonce placement | Top-level and params transition |
Pass nonce inside the provider’s params object |
Accept and verify only the location your current clients send |
| Error property | Read error with code fallback |
Use IdentityCredentialError.error |
Map browser errors to recovery without leaking account state |
| Assertion token | Structured JSON token values supported | No forced migration if the string response still serves the contract | Version response parsing and reject unexpected shapes |
The Chrome 143 update identifies the incompatible changes. If the configuration uses a client_metadata endpoint, the well-known file must include the documented endpoint information; Chrome 145 enforces the accounts_endpoint parameter. The top-level nonce moves into params. IdentityCredentialError.code becomes IdentityCredentialError.error. During 143 and 144, error handling can check error and then code.
Chrome 143 also supports a structured JSON object as the assertion endpoint’s token value. That is an option, not a reason to widen the payload. Return only what the relying party needs, define the accepted shape, and test the relying party against the representation it expects.
How should fallback work?
Feature-detect the capability, but design for user-controlled and browser-controlled absence. FedCM may be unsupported, disabled, cooled down, dismissed, or unable to obtain an account. Preserve an ordinary sign-in control that reaches the existing federation path, plus promised password, passkey, or recovery routes. Keep account linking consistent so a person does not receive a second SaaS identity because the browser used another lane.
Test in a secure context. Chrome’s FedCM setup guide requires HTTPS or localhost for both IdP and RP in Chrome and explains how to test with third-party cookies blocked. It also documents DevTools filtering for FedCM requests in current Chromium-based browsers. Those checks prove request behavior, not usability across browsers; the non-FedCM path needs its own release coverage.
Does the FedCM dialog count as legal consent?
Do not assume it does. Chrome cautions that the sign-in dialog should not be relied on as consent under ePrivacy and data-protection laws in the EEA and UK. If processing beyond authentication needs consent—for example, advertising personalization—obtain it separately. The technical question of whether an exchange can proceed is distinct from the legal basis for later processing.
The broader Chrome identity modernization guidance places federation beside passkeys, recovery, and well-formed account flows. That is a useful boundary: FedCM improves one entry lane. It does not replace phishing-resistant reauthentication, tenant selection, recovery, session revocation, or authorization inside the SaaS product.
