---
url: 'https://www.corbado.com/blog/fedcm-federated-credential-management-api'
title: 'FedCM (Federated Credential Management API) Overview'
description: 'Learn how FedCM replaces third-party cookies with browser-mediated federated login, what browsers support it and how it fits alongside passkeys.'
lang: 'en'
author: 'Vincent Delitz'
date: '2025-12-05T17:16:52.417Z'
lastModified: '2026-03-27T07:01:55.112Z'
keywords: 'FedCM, Federated Credential Management API'
category: 'Authentication'
---
# FedCM (Federated Credential Management API) Overview
**FedCM Browser and Platform Support**
FedCM is a browser API that lets identity providers authenticate users across sites
without tracking cookies.
| **Platform** | **Browser** | **FedCM Support** | **Notes** |
| ------------ | ------------ | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| **Desktop** | Chrome 117+ | ✅ Full support | [Initial beta in 108](https://privacysandbox.google.com/blog/fedcm-shipping); 117+ is the [practical baseline](https://developers.google.com/identity/gsi/web/guides/fedcm-migration) |
| **Desktop** | Edge | ✅ Full support | Chromium-based; Microsoft actively contributing to spec |
| **Desktop** | Firefox | ⚠️ In Development | [Mozilla actively implementing "Core" spec](https://firefox-source-docs.mozilla.org/dom/fedcm.html); shipping expected 2025-2026 |
| **Desktop** | Safari | ❌ Not supported | No public signals; Apple focusing on passkeys |
| **Android** | Chrome 117+ | ✅ Full support | Bottom-sheet UI; [117+ is the practical baseline](https://developers.google.com/identity/gsi/web/guides/fedcm-migration) |
| **Android** | WebView | ❌ Not supported | Use Chrome Custom Tabs instead |
| **iOS** | Safari | ❌ Not supported | No implementation planned; passkey focus |
| **iOS** | Chrome (iOS) | ❌ Not supported | Uses WebKit engine, limited by Safari |
## Key Facts
- **Browser-mediated federation** replaces third-party cookies in FedCM, letting users
sign in with external identity providers without enabling cross-site tracking.
- Chrome 117+ delivers full FedCM support; Google made FedCM **mandatory for all One Tap
and Sign-In button implementations** in August 2025.
- **Axel Springer** reported a 14x increase in monthly registrations after deploying
FedCM, along with reduced spam and fake account registrations.
- FedCM's **navigator.credentials.get()** API requires IdPs to publish manifest files,
implement specific endpoints and verify the Sec-Fetch-Dest: webidentity header on all
requests.
- Safari has **no FedCM implementation planned**; Firefox is actively building support
with shipping expected between 2025 and 2026.
## 1. Introduction: End of Third-Party Cookie Era
The architecture of the World Wide Web is currently undergoing its most significant
structural transformation in over two decades. For the better part of the commercial
internet's history, the mechanisms that underpin
[digital identity](https://www.corbado.com/blog/digital-identity-guide) - the ability for a user to seamlessly
log in to a website using their credentials from another platform - have relied on a
specific, fragile and increasingly controversial primitive: the third-party cookie. These
silent data packets, passed between domains, have acted as the invisible glue of the
federated identity ecosystem, allowing Identity Providers (IdPs) like Google,
[Facebook](https://www.corbado.com/blog/facebook-passkeys) and various enterprise authentication services to
maintain user sessions across the vast expanse of the web.
However, we are now witnessing the final act of the "Cookiepocalypse." Driven by a
convergence of rising consumer demand for digital privacy, stringent regulatory frameworks
such as the General Data Protection Regulation (GDPR) in Europe and the California
Consumer Privacy Act (CCPA) and unilateral enforcement by browser vendors, the era of
[unrestricted cross-site tracking is drawing to a close](https://privacysandbox.google.com/blog/cookie-countdown-2023oct).
The "Privacy Sandbox" initiative, spearheaded by Google Chrome, represents a fundamental
reimagining of web standards, aiming to
[deprecate third-party cookies entirely](https://developer.mozilla.org/en-US/blog/goodbye-third-party-cookies/)
to dismantle the pervasive ad-tracking networks that have flourished in the shadows of
legitimate web activity.
While the primary target of this architectural purge is invasive surveillance capitalism,
the federated identity protocols that power the modern login experience have become
collateral damage. The convenient, seamless authentication flows that users have grown
accustomed to - where a session is silently verified in a hidden
[iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) to keep a user logged in without interruption -
are
[technically indistinguishable from tracking pixels](https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API)
to a browser's privacy filter. When a browser blocks a third-party cookie intended for an
ad network, it inadvertently blocks the session cookie required for an OpenID Connect
(OIDC) silent refresh, breaking the login experience.
Now, there's Federated Credential Management API or FedCM.
**FedCM is already live at scale.** When you click "Sign in with Google" on sites like
[LinkedIn](https://www.corbado.com/blog/linkedin-passkeys), Reddit, Notion, or any of the millions of websites
using [Google Identity Services](https://developers.google.com/identity/gsi/web), that
authentication flow now runs through FedCM in Chrome.
Google completed its migration to FedCM in October 2024 and made it
[mandatory for all One Tap and Sign-In button implementations in August 2025](https://developers.google.com/identity/sign-in/web/gsi-with-fedcm).
FedCM is a standardized restructuring of how identity federation functions on the open
web. It represents a shift from "implicit" federation, where cookies flew freely between
servers, to "explicit,"
[browser-mediated federation](https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API).
By introducing a purpose-built JavaScript API, FedCM moves the responsibility of managing
the handshake between the Identity Provider (IdP) and the
[Relying Party](https://www.corbado.com/glossary/relying-party) (RP) out of the opaque network layer and into the
control of the [user agent](https://www.corbado.com/blog/client-hints-user-agent-chrome-safari-firefox) - the
browser itself.
For Product Managers, FedCM represents a complex duality of risk and opportunity. The risk
is operational and metric-based: the disruption of established conversion funnels. As
browsers enforce new requirements for
["explicit user gestures" and "reconfirmation"](https://developers.google.com/identity/gsi/web/guides/fedcm-migration)
to prove intent, the friction inherent in signup flows is liable to increase, potentially
depressing user acquisition metrics in the short term. The opportunity, however, is
strategic: the chance to leverage a more native, trusted user interface that could
ultimately
[increase user confidence, reduce phishing risks](https://developer.chrome.com/blog/private-user-authentication-fedcm-seznam)
and standardize the login experience across the web.
For Developers and Architects, FedCM introduces a new paradigm of implementation. It
replaces the reliance on fragile [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) redirects and
cookie hacks with a structured, declarative API (`navigator.credentials.get`). It demands
the implementation of new HTTP headers, the hosting of specific manifest files and strict
adherence to
[privacy-preserving protocols that prevent the IdP from learning which sites a user visits](https://developer.chrome.com/docs/identity/fedcm/implement/identity-provider)
without their consent. It is no longer sufficient to simply "drop in a script" and hope
for the best; developers must now orchestrate a browser-mediated negotiation of trust.
This article serves as a guide to the FedCM landscape. We will dissect the technical
implementation details, explore the product implications for user acquisition and
retention and contrast this new federation standard with the parallel rise of passkeys. We
will demonstrate how a modern identity strategy involves navigating these browser-level
shifts and how platforms like Corbado can insulate enterprises from this volatility while
accelerating the transition to a passwordless future.
**Key Questions this Article Answers:**
1. **Why is FedCM necessary?** What problem does it solve and why can't we continue using
traditional federated login?
2. **How does FedCM work technically?** What are the key implementation requirements for
Identity Providers and Relying Parties?
3. **What is the impact on conversion rates?** Will adding FedCM friction hurt user
acquisition?
4. **Should we invest in FedCM or Passkeys?** Which authentication method is the better
long-term strategy?
5. **What should we do right now?** What are the immediate action items for product
managers and developers?
## 2. Context: why the Web is breaking
To fully appreciate the necessity and design of FedCM, one must first understand the
specific architectural failures of the legacy web that necessitated its creation. The
deprecation of third-party cookies is not a sudden, capricious decision by browser vendors
but the culmination of a decade-long cold war between privacy advocates and the ad-tech
industry.
### 2.1 Legacy Architecture of Federation
In the traditional model of identity federation (encompassing protocols like OIDC, SAML
and [OAuth 2.0](https://www.corbado.com/glossary/oauth2)), the mechanism relied heavily on the browser's
willingness to attach cookies to cross-site requests. When a user visits a website (the
[Relying Party](https://www.corbado.com/glossary/relying-party) or RP) and attempts to sign in using an external
provider (the Identity Provider or IdP), the flow typically involves the following unseen
mechanics:
1. **The Session Establishment:** The user logs into the IdP (e.g. `idp.example.com`) in a
separate tab or window. The IdP sets a session cookie in the user's browser, scoped to
`idp.example.com`.
2. **The Cross-Site Request:** When the user subsequently visits `relying-party.com`, the
RP often embeds a resource - typically a JavaScript widget, a "Sign in with..." button,
or an invisible [iframe](https://www.corbado.com/blog/iframe-passkeys-webauthn) - sourced from
`idp.example.com`.
3. **The Cookie Transmission:** Under the legacy model, the browser would automatically
attach the `idp.example.com` cookie to this request, even though the request originated
from `relying-party.com`.
4. **The Verification:** The IdP receives the request, identifies the valid session cookie
and returns a token or a UI state indicating, "Yes, User X is currently logged in."
This mechanism, known as "legacy third-party cookie access," allowed for great user
experiences. It enabled
["silent authentication" and "session extension,"](https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API)
where a user returning to a site could be automatically logged in or have their session
refreshed without any user interaction, simply because they were still logged into their
Google or [Facebook](https://www.corbado.com/blog/facebook-passkeys) account in the background.
### 2.2 Privacy Failure
The fatal flaw in this architecture is its lack of context. The browser, functioning as a
dumb pipe, cannot distinguish between a legitimate identity check performed by an IdP and
a tracking pixel fired by an advertising network. An ad network can utilize the exact same
mechanism: embed a 1x1 invisible pixel on `relying-party.com`, receive the cookie from
`ad-network.com` (which was set when the user visited a different site) and log the fact
that "User X visited [Relying Party](https://www.corbado.com/glossary/relying-party) Y at Time Z."
This capability allowed companies to construct vast, non-consensual profiles of user
behavior across the entire web, linking browsing history, purchase behavior and
demographic data without the user's explicit knowledge or consent. This "cross-site
tracking" is the fundamental privacy violation that modern browsers are engineered to
stop.
### 2.3 Browser Response: the Privacy Sandbox
Browsers like Apple's Safari (with Intelligent Tracking Prevention or ITP) and Mozilla's
Firefox (with Enhanced Tracking Protection) began aggressively blocking these cookies
several years ago. Google Chrome, balancing its massive role in the global advertising
ecosystem with growing privacy demands, launched the
[Privacy Sandbox initiative](https://privacysandbox.google.com/cookies). The goal was to
deprecate third-party cookies entirely, forcing the industry to adopt privacy-preserving
alternatives for measurement, ad selection and fraud detection.
As Chrome began
[rolling out these restrictions](https://privacysandbox.google.com/blog/cookie-countdown-2023oct)
starting with 1% of users in early 2024 and planning for a full rollout - the "silent"
authentication flows began to shatter. If a user had third-party cookies disabled (either
by choice or by browser default), the IdP could no longer see its own session cookie when
called from the RP. The user would appear logged out, the widget would fail to load, or
the silent refresh loop would error out.
### 2.4 Collateral Damage to Identity
This breakage threatened to degrade the user experience of federated login significantly.
Without third-party cookies, the only reliable way to log in with an IdP was to perform a
"top-level redirect" - navigating the user's entire window away from the RP to the IdP and
then back again. While secure, this is disruptive, slow, and introduces a heavy context
switch that is known to kill [conversion rates](https://www.corbado.com/blog/logins-impact-checkout-conversion)
and disrupt user flow.
FedCM was born from this necessity. It is the specialized
["carve-out" in the Privacy Sandbox](https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API)
that effectively states: "We will allow third-party identity checks to occur, but only if
the browser mediates them, strips them of their tracking potential and ensures the user
explicitly consents to the exchange". It is the compromise that saves federated identity
from the extinction of the cookie.
## 3. FedCM Technical Deep Dive
FedCM is designed to abstract the complexity of federation into a browser API. Instead of
the RP talking directly to the IdP via cookies and hidden
[iframes](https://www.corbado.com/blog/iframe-passkeys-webauthn), the RP asks the browser to fetch credentials
and the browser talks to the IdP on the RP's behalf. This section details the technical
architecture, the protocol flow, and the implementation requirements for developers.
### 3.1 Architecture of Intervention
In the FedCM model, the browser acts as a trusted intermediary, introducing a "triangle of
trust" between the User, the Relying Party (RP) and the Identity Provider (IdP).
- **Relying Party (RP):** The website the user is visiting (e.g. an
[e-commerce](https://www.corbado.com/passkeys-for-e-commerce) store) which desires to authenticate the user.
- **Identity Provider (IdP):** The service holding the user's account (e.g. Google, Okta,
or a custom enterprise auth server) which can vouch for the user's identity.
- **User Agent (Browser):** Chrome (and increasingly other browsers), which controls the
User Interface and mediates the network requests.
The browser guarantees that the RP cannot see the user's identifiers or account status at
the IdP until the user explicitly clicks "Continue as \[Name]" in the browser-controlled
UI. Conversely, the browser ensures the IdP cannot track the user visiting the RP unless
the user actually initiates the sign-in flow. This creates a
[privacy firewall, preventing the "pixel tracking" vector](https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API)
that plagued legacy federation.
### 3.2 Protocol Flow: Step-by-Step Anatomy
The FedCM flow involves a specific, orchestrated sequence of HTTP requests and browser
interactions. Unlike the free-for-all of cookie-based federation, FedCM imposes a rigid
structure.
#### 3.2.1 Phase 1: Discovery and Manifest
The IdP must explicitly publish its FedCM capability via a "Well-Known" file and a
configuration file. This is the mechanism by which the browser verifies that the IdP
supports the protocol and where its endpoints are located.
The RP initiates the flow by calling the
[JavaScript API navigator.credentials.get()](https://www.w3.org/TR/fedcm/), pointing
specifically to the IdP's configuration URL.
```javascript
const credential = await navigator.credentials.get({
identity: {
providers: [
{
configURL: "https://idp.example/fedcm.json",
clientId: "your-client-id",
nonce: "randomNonceValue",
},
],
},
mediation: "optional", // or 'required' / 'silent'
// mode: 'passive', // or 'active' if you want to mention modes
});
if (credential) {
const token = credential.token; // send to your backend for verification
}
```
Upon executing this call, the browser fetches the `configURL`. This JSON file acts as the
roadmap for the interaction, containing links to other critical endpoints:
- `accounts_endpoint`: The URL where the browser asks "Who is logged in?"
- `client_metadata_endpoint`: The URL serving metadata like privacy policies and terms of
service.
- `id_assertion_endpoint`: The URL where the browser exchanges a user selection for an
authentication token.
- `branding`: Definitions for how the IdP should look in the browser UI (icons, colors).
#### 3.2.2 Phase 2: Account Status Check and privacy-preserving Fetch
The browser makes a credentialed request (sending the IdP's first-party cookies) to the
`accounts_endpoint` of the IdP.
**Crucially**, this request is stripped of identifying information about the Relying
Party. It typically does not contain the Referer header or the `client_id` parameter. This
ensures that the IdP does not know _who_ is asking yet; it only knows that the browser is
checking the session status. This
[prevents the IdP from building a graph of user activity](https://developer.chrome.com/docs/identity/fedcm/implement/identity-provider)
across RPs just by serving account checks.
The IdP responds with a list of active sessions for that browser profile, providing the
user's name, email and avatar URL.
#### 3.2.3 Phase 3: Browser Native UI
If the IdP returns active accounts, the browser (not the website) renders a native dialog.
This dialog displays the user's avatar, name and email address in a standardized format.
**Privacy Feature:** This UI is drawn by the browser engine (e.g. Chromium), effectively
preventing the RP from "clickjacking," spoofing the IdP login screen, or overlaying
confusing elements. The RP cannot style this box; it is part of the browser chrome,
distinct from the web page's DOM. This visual separation helps users distinguish between a
legitimate browser prompt and a potentially malicious website popup.
#### 3.2.4 Phase 4: Token Issuance and Assertion
If the user clicks the account in the browser UI, indicating their intent to sign in, the
browser sends a POST request to the `id_assertion_endpoint`.
This request includes the specific data needed to finalize the login:
- The `account_id` selected by the user.
- The `client_id` of the RP (now revealed to the IdP, as the user has consented).
- The nonce provided by the RP.
- **Disclosure:** disclosure_text_shown: true (indicating the user saw the privacy
notice).
The IdP validates this request, checks the nonce, and returns an Identity Token (typically
a JSON Web Token or JWT). The browser then
[resolves the JavaScript Promise on the RP side](https://developer.chrome.com/docs/identity/fedcm/implement/identity-provider),
handing over the token to the website's application logic.
### 3.3 Critical Technical Requirements and Security Measures
#### 3.3.1 Sec-Fetch-Dest: webidentity
To prevent Cross-Site Request Forgery (CSRF) attacks where a malicious site might try to
trick an IdP into issuing tokens, browsers tag all FedCM requests with a special,
immutable HTTP header:
`Sec-Fetch-Dest: webidentity`
IdP servers **must** be configured to check for this header. If a request arrives at the
ID [assertion](https://www.corbado.com/glossary/assertion) endpoint without this header, it must be rejected
immediately. This header is
[browser-provided request metadata](https://developer.chrome.com/docs/identity/fedcm/implement/identity-provider)
that signals the request originated from the FedCM API. While not a cryptographic
guarantee, it serves as a critical CSRF defense mechanism - browsers enforce that only
legitimate FedCM flows can set this header, making it difficult for malicious scripts to
forge.
#### 3.3.2 CORS and Origin Matching
The IdP must explicitly allow the RP to use its services via
[Cross-Origin](https://www.corbado.com/blog/iframe-passkeys-webauthn) Resource Sharing (CORS). The `configURL`
and other endpoints must return headers permitting the RP's origin. This replaces the
legacy method of simply whitelisting redirect URIs in a database. While `client_id`
validation still serves the logical permission check,
[CORS provides the network-level enforcement](https://www.w3.org/TR/fedcm/).
#### 3.3.3 "Login Status" API
A major optimization introduced in FedCM is the "Login Status" API. To prevent the browser
from constantly polling the IdP (which wastes bandwidth and leaks timing information), the
IdP must proactively inform the browser when a user logs in or out.
The IdP executes JavaScript on its own domain (e.g. on its login success page):
```javascript
// On IdP login page success
navigator.login.setStatus("logged-in");
// On IdP logout
navigator.login.setStatus("logged-out");
```
This sets a boolean flag in the browser's internal storage. If the status is "logged-out,"
the browser will instantly reject any `navigator.credentials.get` call from an RP without
even making a network request to the IdP. This creates a highly performant "fail-fast"
mechanism, improving page load times and reducing server load for the IdP.
**Key FedCM Implementation Headers**
| **Header** | **Purpose** | **Required?** |
| -------------------------------------------- | ---------------------------------------------------- | ------------------------- |
| Sec-Fetch-Dest: webidentity | Sent by Browser. Proves request is from FedCM API. | **Yes** (IdP must verify) |
| Permissions-Policy: identity-credentials-get | Allows iframe to call FedCM API. | **Yes** (if in iframe) |
| Access-Control-Allow-Origin | CORS header allowing RP to contact IdP. | **Yes** |
| Set-Login: logged-in | HTTP header to update browser's login status signal. | **Recommended** |
### 3.4 Modes and New APIs
FedCM supports different “modes” to accommodate various user-experience patterns, from
subtle sign-in hints to explicit login actions. In recent Chrome updates, Google has
refined how these modes work and introduced new APIs to give relying parties more control.
#### 3.4.1 Passive Mode (Default)
Passive mode is the default FedCM behavior. It is used for “Sign in with…” widgets or
scenarios where the page content is primary and the browser should behave conservatively.
In passive mode, the UI is intentionally subtle (a “quiet” UI) and appears only when the
user is likely interested in signing in.
Using the Multi Identity Provider API, passive mode can present multiple identity
providers or multiple accounts in a unified chooser. This helps avoid the “NASCAR” effect
of many separate sign-in buttons and is ideal for users who have accounts with more than
one provider.
#### 3.4.2 Active Mode
Active mode is triggered by an explicit user gesture, such as clicking a “Login” button.
When active mode is used, the browser is allowed to be more assertive in presenting UI
—-including stepping out of the subtle “quiet UI” into a modal dialog when appropriate.
This mode is optimized for flows where the user clearly expresses login intent.
Developers can request active mode explicitly via:
```javascript
mode: "active";
```
#### 3.4.3 Button Mode API (Recommended for Active Mode)
As part of the ongoing evolution of FedCM, Google introduced the Button Mode API, which
builds on active mode and provides clearer control over gesture-initiated sign-in flows.
With Button Mode:
- The UI is always triggered by a direct user action.
- FedCM can show a more prominent, modal authentication surface.
- The relying party gets better control over when and how FedCM appears.
In practice, Button Mode is the recommended way to use active mode: it turns a previously
implicit concept (“user gesture required”) into an explicit, well-defined API surface.
### 3.5 Upcoming Features (2026 Roadmap)
Based on the W3C FedID Working Group meetings in late 2025, several significant features
are in development:
**Continuation API:** This API allows identity providers to use custom pop-up windows for
gathering additional permissions. It provides more flexibility in how IdPs explain
permission requests to users, which is particularly useful for complex authorization
scenarios that go beyond simple authentication.
**Navigation Interception API:** Currently being prototyped by Google, this allows IdPs to
return a header during OAuth redirect flows that triggers FedCM instead of completing the
navigation. This is transformative for adoption because **RPs don't need to change
anything** - existing OAuth redirect implementations can be upgraded to FedCM by the IdP
alone. This also opens doors for agentic browsers where AI agents can use federation as a
structured tool.
**FLUX / Unified Sign-in:** Chrome is working on consolidating passwords, passkeys and
federated logins into a single credential selector. This reduces the "mental load of
determining what they used last time" for returning users.
**Conditional Get (Autofill Integration):** FedCM accounts appearing alongside passkeys in
the browser's autofill dropdown, similar to [how passkeys work](https://www.corbado.com/faq/how-do-passkeys-work)
with [Conditional UI](https://www.corbado.com/glossary/conditional-ui). This is behind a flag in Chrome Canary.
**Email Verification Protocol:** An experimental protocol allowing cryptographic proof of
email ownership without magic links. The browser would fetch verification from email
providers, eliminating context-switching to inboxes. This is being discussed for potential
inclusion in the FedID working group.
**Lightweight FedCM:** A set of optimizations including "accounts push" (IdP proactively
tells browser about logged-in accounts) and "config push" to reduce network requests and
latency.
### 3.6 Handling Iframes and Permissions Policy
A common implementation stumbling block is using FedCM inside an iframe (e.g. a login
widget embedded in a modal or a third-party [payment](https://www.corbado.com/passkeys-for-payment) flow). By
default, the browser blocks third-party [iframes](https://www.corbado.com/blog/iframe-passkeys-webauthn) from
invoking powerful APIs like FedCM to prevent abuse.
Developers must explicitly grant permission in the HTML of the iframe:
```html
```
Furthermore, the HTTP response headers of the document served inside the iframe must
include a [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) header:
`Permissions-Policy: identity-credentials-get=(self "https://rp.example")`
This strict permissioning ensures that only
[authorized widgets can trigger the browser's identity UI](https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API).
### 3.7 Real-World Implementations (2025)
**Shopify (Sign in with Shop):** At TPAC 2025, [Shopify](https://www.corbado.com/blog/shopify-passkeys) presented
their FedCM implementation serving millions of [merchants](https://www.corbado.com/glossary/merchant). Key
insights:
- FedCM helps solve the "SMB identity disadvantage" - small
[merchants](https://www.corbado.com/glossary/merchant) lack the rich user data of large
[marketplaces](https://www.corbado.com/passkeys-for-e-commerce)
- Cross-device cart syncing becomes easier when users are logged in
- They're interested in: autofill integration, modal UI for high-intent sign-ins, better
branding options, multi-IdP support, and improved metrics
**Axel Springer (Welt, Bild):** German media giant with full FedCM deployment:
- **14x increase in monthly registrations** after implementing FedCM
- Reduced spam/fake registrations
- 75% of their traffic is mobile web, making FedCM's bottom-sheet UI particularly valuable
- Challenge: Some IdPs (like NetID) use native apps rather than browser sign-in, requiring
workarounds
**Microsoft:** Active contributor on both browser (Edge) and IdP (Entra ID) sides:
- Focus on enterprise scenarios: admin consent, composed experiences (Outlook embedding
Zoom, Salesforce embedding Word)
- Developing "nested app authentication" patterns
- Pushing for same-auth iframe support
## 4. FedCM Product Deep Dive
While the technical mechanics of FedCM are complicated, the implications for product
managers are perhaps even more profound. The shift to FedCM fundamentally alters the user
journey, the conversion funnel and the metrics used to measure identity success. It forces
a relinquishing of control in exchange for standardization and trust.
### 4.1 UX Transformation: from Widget to Browser
In the legacy model, a product team had near-total control over the "Sign in with Google"
button. They could style it (within brand guidelines), place it anywhere on the page,
animate it and control the loading state. The experience was fully integrated into the DOM
of the website.
With FedCM, the actual account selection moves into the browser- the User Interface
elements that belong to the browser application itself (like the URL bar or the bookmarks
menu), not the web page.
**The "Bubble" vs. The "Sheet":**
- **The Bubble:** On desktop browsers, FedCM often appears as a small, unobtrusive bubble
in the top-right corner of the browser window, near the user's profile icon. It is
subtle and non-blocking, designed to be helpful rather than demanding.
- **The Sheet:** On mobile devices (particularly
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android)), it typically appears as a bottom-sheet
drawer, a standard mobile interaction pattern that slides up from the bottom of the
screen.
**Product Implication:** PMs must account for this loss of UI control. You cannot force
the FedCM prompt to be "bigger," "red," or "flashy." You cannot impose your brand's font
on the account chooser. You must trust the browser's native, recognizable UI. However,
this standardization can actually **increase trust**. As users learn to
[recognize the browser's secure prompt](https://github.com/w3c-fedid/FedCM) over a random
HTML popup, they may become more likely to engage with it, viewing it as a verified system
process rather than a website marketing tactic.
### 4.2 "Reconfirmation" Friction
One of the most contentious aspects of FedCM for Product Managers is the "Automatic
Sign-in" behavior and the introduction of friction.
Previously, if a user had authorized an app, they could be signed in instantly upon return
via a silent iframe refresh. The user might not even realize a check occurred. With FedCM,
specifically in newer versions of Chrome (M121+), the browser emphasizes **explicit user
gestures**. Even if a user has signed in before, the browser may require a
["Reconfirmation" - a specific click in the browser UI](https://developers.google.com/identity/gsi/web/guides/fedcm-migration)
to confirm they want to sign in again.
**Impact on Conversion:** This introduces a "click" where there used to be zero clicks.
For high-velocity apps (e.g. news sites, casual games,
[e-commerce](https://www.corbado.com/passkeys-for-e-commerce) checkouts), this additional friction point can drop
[login conversion](https://www.corbado.com/blog/login-friction-kills-conversion) rates. Google's own
documentation warns developers that this change
["may cause an initial disruption in automatic sign-in conversion rates"](https://developers.google.com/identity/gsi/web/guides/fedcm-migration).
However, real-world data from early adopters paints a **dramatically positive** picture:
**Axel Springer (Welt, Bild) reported at TPAC 2025:**
> "We have **14x more monthly registrations** with FedCM comparing a Jan-May period to
> Jun-Oct period. It's extremely successful, no other strategy works as well for stable
> logins."
They also noted that FedCM reduced spam registrations: "When with a normal login flow we
have extremely spammy email addresses and normally we have many fake emails and fake
credit card registrations we have to filter, it's good to have FedCM as a service that
limits that."
Metrics from Seznam, a major Czech internet company, suggest that despite the friction,
the _clarity_ of the flow can lead to
[higher overall engagement](https://developer.chrome.com/blog/private-user-authentication-fedcm-seznam).
Because users are less confused by redirects or pop-ups that might get blocked by
aggressive popup blockers, the net successful sign-ins may actually increase or stabilize
at a higher quality level. The "quality" of the sign-in improves because it is
intentional.
### 4.3 "NASCAR" Problem and Account Choosers
The "NASCAR problem" refers to login pages that are covered in a confusing array of logos
(Google, [Facebook](https://www.corbado.com/blog/facebook-passkeys), X, Apple, etc.), resembling the sponsor
decals on a race car. This cognitive load often leads to decision paralysis.
FedCM attempts to solve this by allowing multiple providers to be listed in a single,
unified browser UI. The `navigator.credentials.get` call accepts an array of providers:
```JavaScript
const credential = await navigator.credentials.get({
identity: {
providers: [
{ configURL: 'https://accounts.google.com/gsi/fedcm.json', clientId: 'google-client-id' },
{ configURL: 'https://idp.netid.de/fedcm.json', clientId: 'netid-client-id' },
{ configURL: 'https://login.shopify.com/fedcm.json', clientId: 'shop-client-id' }
]
}
});
```
The browser then aggregates these into a single "Choose an account" list, displaying the
user's active sessions across different providers in one clean interface.
**Strategic Insight:** This commoditizes the Identity Provider. The user sees a list of
_accounts_ (Jane Doe @ Gmail, Jane Doe @ Facebook), not just a list of _brands_. This
subtle shift levels the playing field between large IdPs and smaller ones, provided they
support FedCM. It focuses the user on the _identity_ rather than the _provider_,
potentially increasing the
[selection rate for whichever account is currently active](https://github.com/w3c-fedid/FedCM).
### 4.4 Analytics and Blind Spots
A critical challenge for PMs is observability. Because the initial handshake happens
between the browser and the IdP (to protect privacy), the RP's JavaScript often does not
know that a FedCM flow is pending until the user actually selects an account.
If the user closes the browser prompt (ignores it), the RP might not get a distinct
"rejection" event in the same way they could track a closed HTML popup. This changes how
"Abandonment Rate" is calculated and monitored.
**Product Managers need to redefine their funnel steps:**
1. **Intent:** User lands on login page (Page View)
2. **Invocation:** `navigator.credentials.get` is executed (Event: `FedCM_Invoked`)
3. **Presentation:** Browser shows UI (Inferred; often hard to track directly without
successful callback or browser-specific reporting APIs)
4. **Conversion:** Token received (Event: FedCM_Success)
The gap between Step 2 and Step 4 becomes a "Black Box" of browser interaction. PMs must
work closely with engineering to utilize whatever
[error codes (like IdentityCredentialError) are available](https://developer.mozilla.org/en-US/docs/Web/API/FedCM_API)
to infer user behavior.
### 4.5 Current Limitations
Based on the W3C FedID Working Group discussions in 2025, there are important limitations
to be aware of:
**Chained Authentication Flows:** FedCM does **not** support IdP proxies or chained
federation flows. This is critical for education and research sectors where protocol
translation proxies are common, as well as enterprise deployments with multi-lateral
federation. The working group has explicitly stated: "Please make sure you are aware that
there are plenty of use cases in identity federation that are not solvable by FedCM
today." For these scenarios, traditional redirect flows remain necessary.
**Enterprise Scenarios:** Microsoft is actively pushing for better enterprise support,
including:
- **Admin consent** (IT admin pre-approving IdP-RP relationships instead of end-user
consent)
- **Composed experiences** (iframes embedded in "super apps" like Teams or Copilot needing
the same identity as the parent)
- **BYOD challenges** (how to signal trust when the device isn't managed)
These are being discussed but not yet solved.
**\~130 Open Issues:** The FedCM spec has approximately 130 open issues. The working group
is targeting W3C Candidate Recommendation status, which requires multiple independent
implementations (hence Mozilla's involvement is critical).
## 5. Recommendations
Based on our analysis, here are the key recommendations for organizations navigating the
FedCM transition:
**For Immediate Action:**
- **Audit your login flows now:** Identify any reliance on silent iframe refreshes or "One
Tap" auto-login - these will break without FedCM as third-party cookie deprecation rolls
out.
- **Test in Chrome Canary:** The FedCM API is evolving rapidly. Test with feature flags
enabled to anticipate breaking changes 2-3 releases ahead.
- **Implement Permissions-Policy headers** if you use
[iframes](https://www.corbado.com/blog/iframe-passkeys-webauthn) for authentication widgets. FedCM is blocked
in iframes by default.
**For Strategic Planning:**
- **Adopt a hybrid strategy:** Use FedCM/[Social Login](https://www.corbado.com/glossary/social-login) for
low-friction user acquisition at the top of funnel, then upsell users to Passkeys for
long-term retention and security.
- **Accept short-term friction for long-term gains:** FedCM's reconfirmation requirements
may cause an initial disruption in auto-login conversions, but the clarity of explicit
consent leads to higher-quality sign-ins.
- **Plan your IdP compatibility:** If using [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis), Okta,
or Firebase, verify their FedCM roadmap. If running a custom IdP, budget significant
development time to implement the [W3C FedCM spec](https://www.w3.org/TR/fedcm/).
**For Long-Term Success:**
- **Prioritize Passkeys as your endgame:** FedCM maintains dependency on third-party IdPs.
Passkeys give you ownership of the user relationship (first-party) with faster,
[phishing](https://www.corbado.com/glossary/phishing)-resistant authentication.
- **Update your analytics:** Redefine funnel metrics to account for the "black box" of
browser-mediated interaction between FedCM invocation and token receipt.
## 6. How Corbado helps
Navigating this dual transformation - scrambling to implement FedCM to salvage legacy
[social login](https://www.corbado.com/glossary/social-login) flows while simultaneously attempting to build for
a passwordless future with passkeys - is a massive engineering and strategic burden. Most
internal identity teams are already stretched thin maintaining existing integrations.
This is where Corbado positions itself as the "Identity Orchestration" layer. Corbado
abstracts the complexity of modern authentication, allowing enterprises to focus on their
core product rather than chasing browser API changelogs and W3C specification drafts.
### 6.1 Shielding Developers from Browser Churn
FedCM is still technically "Experimental" in many aspects. The API surface is changing.
Browser support varies (Chrome is ahead, while Firefox and Safari have different timelines
and implementation details). Maintaining a custom FedCM integration requires constant
vigilance.
**Browser Positioning (as of December 2025):**
- **Firefox:** Mozilla is
[actively implementing FedCM](https://firefox-source-docs.mozilla.org/dom/fedcm.html) as
a "Core" specification. Ben VanderSloot from Mozilla has been contributing to spec
discussions and implementation. Focus is on accounts pull, Active Mode, continuation
API, and login status API. Mozilla's goal: "envision a world where there are no storage
access heuristics."
- **Safari:** No public implementation signals. Apple's authentication focus is entirely
on passkeys. The W3C FedID working group notes: "We've not historically seen Safari
participation."
**How Corbado helps:**
- **Managed UI Components:** Corbado provides pre-built, high-conversion UI components
(Sign-up/Login screens) that handle the underlying complexity. If the user's browser
supports FedCM, Corbado's components (or the underlying providers it integrates with)
leverage it automatically. If the browser does not support it (e.g. an older version),
the system gracefully falls back to standard redirects or popups.
- **Future-Proofing:** By integrating the Corbado SDK, developers effectively outsource
the maintenance of the auth layer. When Chrome pushes a breaking change to the FedCM
"reconfirmation" logic or modifies the header requirements, Corbado updates its library.
The Relying Party does not need to rewrite their authentication code or redeploy their
backend to stay compliant.
### 6.2. The Passkey-First Approach
Corbado is fundamentally a **Passkey-First** solution. While it supports
[social login](https://www.corbado.com/glossary/social-login) (and thus FedCM), its primary value proposition is
helping companies migrate _away_ from reliance on passwords and legacy federation toward
device-centric authentication.
- **Passkey Intelligence:** Corbado's
"[Passkey Intelligence](https://docs.corbado.com/corbado-connect/features/passkey-intelligence)"
engine analyzes the user's device capabilities (Operating System, Browser Version,
Hardware Availability) in real-time. If the device supports passkeys (e.g. an iPhone
with [Face ID](https://www.corbado.com/faq/is-face-id-passkey) or a Windows laptop with
[Windows Hello](https://www.corbado.com/glossary/windows-hello)), Corbado promotes the passkey flow as the
primary option. If not, it gracefully degrades to email OTP or social login via FedCM.
- **Adoption Tools:** A major hurdle for passkeys is user education. Corbado provides UI
elements that "nudge" users to create passkeys after a successful social login (e.g.
"Login faster next time with FaceID"). This bridges the gap: capture the user with
FedCM/Social to minimize friction at signup, then retain them with passkeys for
long-term engagement.
### 6.3 Analytics and Insight
FedCM creates the observability blind spots discussed earlier. Corbado fills this gap with
its dedicated analytics suite.
- **Funnel Visibility:** Corbado's dashboard provides a unified view of the login funnel,
regardless of the method (FedCM, Passkey, Password, OTP).
- **Error Categorization:** It distinguishes between "User closed the FedCM window"
(abandonment) and "IdP returned an error" (technical failure). This granularity is
critical for PMs attempting to optimize
[conversion rates](https://www.corbado.com/blog/logins-impact-checkout-conversion) and understand why users are
dropping off.
- **Cost Reduction:** By shifting users from expensive SMS OTPs to free Passkeys, and
reducing [password reset](https://www.corbado.com/blog/password-reset-increase-customer-retention) tickets,
Corbado drives measurable ROI, often reducing authentication costs by up to 90%.
### 6.4 Identity Orchestration: Connect vs. Migrate
For enterprises with complex, entrenched stacks (e.g. using Okta for employees but needing
a better CIAM solution for customers, or stuck on a legacy
[Cognito](https://www.corbado.com/blog/passkeys-amazon-cognito) implementation), Corbado offers a flexible
integration model.
**Corbado Connect:** This allows Corbado to act as a layer on top of existing Identity
Providers (like [Auth0](https://www.corbado.com/blog/auth0-passkeys-analysis),
[Cognito](https://www.corbado.com/blog/passkeys-amazon-cognito), or Ping). It injects passkey and FedCM
capabilities into the frontend while keeping the backend user store in the legacy IdP.
This "overlay" approach eliminates the risk of a massive user migration, allowing
companies to modernize their UX immediately without re-platforming their entire user
database.
Summary of Corbado's Value:
Corbado allows organizations to treat "Identity" as a solved problem. Instead of hiring a
specialized team to interpret W3C specs on FedCM and [FIDO2](https://www.corbado.com/glossary/fido2) specs on
WebAuthn, teams can implement Corbado. They get the best of FedCM (social login
continuity) and the best of passkeys (security and UX) in a single, maintained
integration.
## 7. Strategic Pivot: FedCM vs. Passkeys
As organizations scramble to implement FedCM to fix their broken social logins, a deeper
strategic question arises: **Is this the right long-term bet?**
FedCM is, effectively, a "life support" system for the federated identity model in a
privacy-first world. It preserves the ability to say "I am User X on Google" and prove it
to "Website Y." It maintains the status quo of the last decade.
However, there is a parallel revolution happening: **Passkeys**.
### 7.1 Fundamental Difference
- **FedCM (Federated):** Relies on a third party (Google/Apple/Microsoft) to vouch for the
user. The trust anchor is external. The user has "one account to rule them all," which
is convenient but creates a central point of failure, a central point of privacy
concentration, and a dependency on the policy whims of
[big tech](https://www.corbado.com/blog/big-tech-vs-passkey-aggregators).
- **Passkeys (WebAuthn):** Relies on the user's _device_ to vouch for the user. The trust
anchor is the local hardware (Face ID, Touch ID,
[Android](https://www.corbado.com/blog/how-to-enable-passkeys-android) Biometrics). The site stores a public
key. The private key never leaves the user's device. The authentication is local,
cryptographic and inherently phish-proof.
### 7.2 Why Passkeys might be superior
1. **Conversion & Speed:** Passkeys are often faster than FedCM. A Touch ID scan takes
milliseconds. A FedCM flow requires a network round-trip to the IdP to fetch the
accounts list, the rendering of the UI and another round-trip for the token issuance.
Passkeys eliminate the "middleman" latency.
2. **Resilience:** Passkeys do not depend on the availability of a third-party IdP. If
Google's servers are down, "Sign in with Google" (and thus FedCM) is down. If Google is
down, a passkey stored on an iPhone or in a
[password manager](https://www.corbado.com/blog/passkeys-vs-password-managers) still works for the Relying
Party because the validation happens against the RP's own server (via the public key).
3. **Privacy:** Passkeys are inherently private. The "IdP" in the passkey model (usually
the sync provider like [iCloud Keychain](https://www.corbado.com/glossary/icloud-keychain) or
[Google Password Manager](https://www.corbado.com/blog/how-to-use-google-password-manager)) syncs the keys but
does not know when or where they are used. The sync provider just moves encrypted
blobs. In contrast, FedCM, by definition, informs the IdP every single time the user
logs in to a specific site.
**FedCM vs. Passkeys Comparison**
| **Feature** | **FedCM (Federated Credential Management)** | **Passkeys (WebAuthn)** |
| ------------------- | --------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------- |
| **Trust Anchor** | Third-Party Identity Provider (Google, Facebook) | User's Device (Apple Face ID, Windows Hello) |
| **Privacy** | [IdP knows when/where you log in](https://developer.chrome.com/docs/identity/fedcm/implement/identity-provider) | IdP (Sync Provider) does not track usage history |
| **User Experience** | Browser Native UI (Bubble/Sheet). | System Native UI (Biometric Prompt). |
| **Connectivity** | Requires online connection to IdP. | Requires RP server for challenge/verification; no third-party IdP needed. |
| **Implementation** | JS API + IdP Endpoint requirement | WebAuthn API |
| **Corbado Role** | Supports via Social Login integrations & Fallback. | Native, first-class citizen support & analytics. |
**Is FedCM like Conditional UI for Social Login?** Yes, conceptually. FedCM provides
browser-mediated federation and the upcoming "Conditional Get" feature will show FedCM
accounts in the autofill dropdown alongside passkeys - exactly like WebAuthn's Conditional
UI. However, FedCM isn't limited to "social login" - it's a general federated identity
solution that works for enterprise [SSO](https://www.corbado.com/blog/passkeys-single-sign-on-sso) (Microsoft is
heavily invested in enterprise scenarios), [e-commerce](https://www.corbado.com/passkeys-for-e-commerce)
(Shopify), publishers (Axel Springer) and
[decentralized identity](https://www.corbado.com/blog/digital-identity-guide) (Solid, Mastodon via IdP
Registration API).
### 7.3 Hybrid Reality
For the next 3-5 years, the dominant strategy for successful applications will be hybrid.
- **Social Login (via FedCM):** Essential for "Top of Funnel" acquisition. It lowers the
barrier to entry for new users who don't want to create a new account and just want to
"peek" inside the application. It reduces the "Cold Start" problem.
- **Passkeys:** Essential for "Retention, Security, and LTV." Once a user has created an
account (perhaps initially via Social), the smart move is to upsell them to a Passkey.
This removes the dependency on the Social Provider for future logins, enables a seamless
biometric experience, and locks the user into a secure relationship with the brand.
## 8. Conclusion: FedCM
The deprecation of third-party cookies is a watershed moment for the web. It forces a
choice upon every digital business: cling to the hacks of the past or embrace the
structured, privacy-preserving protocols of the future.
**Answering the Key Questions:**
1. **Why is FedCM necessary?** Third-party cookies (the invisible glue of federated
identity) are being blocked by browsers as part of the Privacy Sandbox initiative.
FedCM provides a browser-mediated alternative that preserves "Sign in with..."
functionality while preventing cross-site tracking.
2. **How does FedCM work technically?** FedCM introduces a structured API
(`navigator.credentials.get`) where the browser acts as a trusted intermediary. IdPs
must publish manifest files, implement specific endpoints (`accounts_endpoint`,
`id_assertion_endpoint`), and verify the `Sec-Fetch-Dest: webidentity` header. The
browser renders native UI that cannot be spoofed by websites.
3. **What is the impact on conversion rates?** FedCM's reconfirmation requirements may
cause an initial disruption in automatic sign-in conversions. However, real-world data
from companies like Seznam shows that the clarity of explicit consent leads to
higher-quality, intentional sign-ins and potentially better long-term retention.
4. **Should we invest in FedCM or Passkeys?** Both. FedCM maintains the convenience of
social login for user acquisition, but Passkeys are the superior long-term solution -
faster, phish-proof, and independent of third-party IdP availability. The winning
strategy is hybrid: acquire users via FedCM, then upsell them to Passkeys.
5. **What should we do right now?** Audit your login flows for third-party cookie
dependencies. Implement [Permissions-Policy](https://www.corbado.com/faq/enable-passkeys-iframe) headers if
using iframes. Test in Chrome Canary. Plan your migration path and consider platforms
like Corbado that abstract this complexity.
**The Bottom Line:**
FedCM is the bridge that keeps the convenient "Sign in with..." ecosystem alive. However,
while FedCM saves the past, **Passkeys build the future**. The ultimate goal for any
forward-thinking digital product should be to reduce reliance on third-party identity
providers entirely.
Don't choose one. Use FedCM to lower the barrier for new users entering your funnel. Then,
use Corbado to upgrade those users to Passkeys for a lifetime of frictionless, secure
access. The cookie is dead. Long live Identity.
## Frequently Asked Questions
### How does FedCM prevent identity providers from tracking which sites a user visits?
FedCM's accounts_endpoint fetch strips the Referer header and client_id from the request,
so the IdP only learns that the browser is checking session status, not which relying
party is asking. The IdP only discovers the user's destination site after the user
explicitly clicks 'Continue' in the browser-native UI, at which point the user has
consented.
### What breaks in 'Sign in with Google' flows if FedCM is not implemented?
Silent iframe refresh and One Tap auto-login flows break as browsers block third-party
cookies. The only reliable fallback is a top-level redirect, which navigates users away
from the site and is known to reduce conversion rates. Google made FedCM mandatory for all
Sign-In button implementations in August 2025, making the migration non-optional.
### Why is FedCM unavailable on iOS regardless of which browser app is used?
Chrome on iOS uses the WebKit engine and is constrained by Safari's capabilities. Safari
has no FedCM implementation planned, with Apple focusing its authentication efforts
entirely on passkeys. This means FedCM support is absent across all iOS browsers, not just
Safari itself.
### What is the FedCM Navigation Interception API and who benefits from it?
The Navigation Interception API lets IdPs return a header during existing OAuth redirect
flows that triggers FedCM instead of completing the navigation. Relying parties require no
code changes, meaning existing OAuth redirect implementations can be upgraded to FedCM by
the IdP alone. Google is currently prototyping this feature.
### How should product managers restructure their login funnel analytics after adopting FedCM?
FedCM creates an observability gap because the browser-IdP handshake is invisible to the
relying party's JavaScript until a token is returned. Funnels should track FedCM_Invoked
when navigator.credentials.get() fires and FedCM_Success when the token arrives, treating
the interval as a browser-controlled black box. Error codes like IdentityCredentialError
help distinguish user abandonment from technical IdP failures.