FedCM (Federated Credential Management API) Overview

+70-page Enterprise Passkey Whitepaper:
Learn how leaders get +80% passkey adoption. Trusted by Rakuten, Klarna & Oracle

Get free Whitepaper

FedCM Browser and Platform Support

FedCM is a browser API that lets identity providers authenticate users across sites without tracking cookies.

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 - 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 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. The "Privacy Sandbox" initiative, spearheaded by Google Chrome, represents a fundamental reimagining of web standards, aiming to deprecate third-party cookies entirely 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> to keep a user logged in without interruption - are technically indistinguishable from tracking pixels 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, Reddit, Notion, or any of the millions of websites using Google Identity Services, 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.

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. By introducing a purpose-built JavaScript API, FedCM moves the responsibility of managing the handshake between the Identity Provider (IdP) and the Relying Party (RP) out of the opaque network layer and into the control of the user agent - 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" 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 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> 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 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?

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.

In the traditional model of identity federation (encompassing protocols like OIDC, SAML and OAuth 2.0), 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 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> - 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," 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 account in the background.

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 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.

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. 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 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.

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 and disrupt user flow.

FedCM was born from this necessity. It is the specialized "carve-out" in the Privacy Sandbox 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.

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, 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.

FedCM modal dialog

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 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 that plagued legacy federation.

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.

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(), pointing specifically to the IdP's configuration URL.

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).

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 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.

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.

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, handing over the token to the website's application logic.

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 endpoint without this header, it must be rejected immediately. This header is browser-provided request metadata 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.

The IdP must explicitly allow the RP to use its services via Cross-Origin 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.

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):

// 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

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.

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.

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:

mode: "active"

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.

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 with 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.

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 flow). By default, the browser blocks third-party iframes from invoking powerful APIs like FedCM to prevent abuse.

Developers must explicitly grant permission in the HTML of the iframe:

<iframe src="https://login-widget.com" allow="identity-credentials-get"></iframe>

Furthermore, the HTTP response headers of the document served inside the iframe must include a Permissions-Policy 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.

Shopify (Sign in with Shop): At TPAC 2025, Shopify presented their FedCM implementation serving millions of merchants. Key insights:

• FedCM helps solve the "SMB identity disadvantage" - small merchants lack the rich user data of large marketplaces
• 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

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.

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), 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 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.

FedCM multiple sessions

FedCM single session return user automatic sign-in

FedCM single session returning user

FedCM single session new user

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 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 checkouts), this additional friction point can drop login conversion rates. Google's own documentation warns developers that this change "may cause an initial disruption in automatic sign-in conversion rates".

However, real-world data from early adopters paints a dramatically positive picture:

Axel Springer (Welt, Bild) reported at TPAC 2025:

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. 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.

The "NASCAR problem" refers to login pages that are covered in a confusing array of logos (Google, Facebook, 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:

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.

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 to infer user behavior.

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).

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 for authentication widgets. FedCM is blocked in iframes by default.

For Strategic Planning:

• Adopt a hybrid strategy: Use FedCM/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, Okta, or Firebase, verify their FedCM roadmap. If running a custom IdP, budget significant development time to implement the W3C FedCM spec.

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-resistant authentication.
• Update your analytics: Redefine funnel metrics to account for the "black box" of browser-mediated interaction between FedCM invocation and token receipt.

Navigating this dual transformation - scrambling to implement FedCM to salvage legacy 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.

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 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.

Corbado is fundamentally a Passkey-First solution. While it supports 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" 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 or a Windows laptop with 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.

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 and understand why users are dropping off.
• Cost Reduction: By shifting users from expensive SMS OTPs to free Passkeys, and reducing password reset tickets, Corbado drives measurable ROI, often reducing authentication costs by up to 90%.

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 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, 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 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.

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.

• 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.
• 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 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.

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 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 or 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

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 (Microsoft is heavily invested in enterprise scenarios), e-commerce (Shopify), publishers (Axel Springer) and decentralized identity (Solid, Mastodon via IdP Registration API).

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.

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 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.