FedCM: The Browser‑Built Standard Set to Replace Cookie‑Based Federated Login

The web has long relied on third‑party cookies and redirects to power federated login buttons like “Sign in with Google.” Those same mechanisms, however, enable cross‑site tracking and have become increasingly fragile as browsers phase out third‑party cookies. In response, the World Wide Web Consortium (W3C) is crafting Federated Credential Management (FedCM) – a native browser API that moves the authentication handshake into the browser itself.

Why FedCM Matters

FedCM tackles two pain points that have plagued federated authentication:

1. Privacy erosion – Redirect‑based flows expose the user’s browser to the identity provider (IdP) and the relying party (RP) through iframes and third‑party cookies, making it easy for advertisers to track users across sites.
2. Reliability in a cookie‑free world – With browsers like Safari and the upcoming Chrome privacy mode aggressively blocking third‑party cookies, many existing OIDC and SAML implementations risk breaking.

By letting the browser mediate the exchange, FedCM removes the need for cross‑site cookies and eliminates the redirect dance. The browser presents a native prompt, asks the user which account to use, and hands a signed token directly to the RP.

How the Flow Differs from Traditional OIDC

Below is a high‑level comparison of the two approaches. The diagrams are simplified to illustrate the key steps.

Traditional Redirect‑Based OIDC

1. User visits protected resource.
2. RP redirects to IdP.
3. User logs in on IdP page.
4. IdP redirects back to RP with an authorization code.
5. RP exchanges code for tokens.
6. User session is established.

The user is bounced between the RP and IdP, and every hop relies on cookies or URL parameters.

FedCM Passive Mode (the friction‑less path)

1. User visits protected resource.
2. RP includes FedCM API JavaScript.
3. Browser calls FedCM API to request credentials.
4. If the user is not logged in to the IdP, a native prompt appears.
5. User selects an account (or logs in if necessary).
6. Browser receives a signed token and returns it to the RP.
7. RP validates the token and creates a session.
8. User gains access.

On the first visit, the user may still need to log in, but subsequent visits are seamless: the browser automatically re‑authenticates the user without any redirects or pop‑ups.

Adoption Landscape

• Chrome and Edge – Both browsers already support FedCM, covering the majority of desktop traffic.
• Safari – No support as of now; Apple’s roadmap is unclear.
• Firefox – The team paused implementation in August 2025, citing prioritization of other features.
• Identity Providers – Google has already started adopting FedCM through its Identity Services library. FusionAuth has not yet implemented the spec, though an open tracking issue exists.

Because the standard is still a working draft (published August 2024), developers should maintain fallback mechanisms for browsers that do not yet support FedCM or for users who disable the feature.

What This Means for Developers

• Simplified integration – Instead of wiring up redirects, token exchanges, and cookie handling, developers can call navigator.credentials.get({ federated: { provider: 'https://accounts.google.com' } }) and handle the returned token.
• Better privacy guarantees – The browser controls which claims are exposed to the RP, reducing the attack surface for cross‑site tracking.
• Future‑proofing – As third‑party cookies disappear, FedCM provides a path forward that aligns with the evolving privacy landscape.

Practical Steps

1. Check browser support – Use feature detection (if ('credentials' in navigator && 'get' in navigator.credentials) { … }).
2. Implement fallback – Continue supporting OIDC or SAML for legacy browsers.
3. Test token validation – Validate the JWS returned by the browser against the IdP’s JWKS endpoint.
4. Monitor the spec – Follow the W3C working group to stay abreast of changes.

Looking Ahead

FedCM is still evolving, but its trajectory suggests a shift toward browser‑native authentication. As privacy regulations tighten and user expectations for seamless sign‑ins grow, FedCM could become the de‑facto standard for federated login. Developers who adopt it early will benefit from a cleaner, more secure authentication flow that aligns with the browser’s built‑in privacy controls.

For deeper dives, the W3C working group publishes a public draft and welcomes community contributions. The spec’s evolution will be closely watched by the identity and security communities alike.