FedCM Guide: Federated Credential Management API

"Sign in with" buttons and embedded identity widgets were built on third-party cookies, iframes and redirects, and those building blocks are being restricted by browsers for privacy reasons. Federated Credential Management (FedCM) is a browser API, developed in the W3C Federated Identity Working Group, that lets the browser itself mediate federated sign-in between a relying party (RP) and an identity provider (IdP) without exposing the user to cross-site tracking. This guide explains the FedCM flow, the IdP configuration files and endpoints, the Login Status API, how FedCM fits with OpenID Connect, the security checks each side must make and how to roll it out alongside existing flows. It is for CIAM architects, IdP and RP engineers and security reviewers. FedCM is a different browser API from the one that presents verifiable credentials and digital identity documents, which is covered in the W3C Digital Credentials API Guide. Facts below come from the W3C specification and browser vendors' own documentation, checked in November 2026; browsers are listed alphabetically.

Key takeaways

The browser becomes the broker. The RP calls navigator.credentials.get() with an identity option, the browser fetches the IdP's configuration and accounts, shows its own account chooser and returns a token from the IdP to the RP.
It is still a draft. The W3C publication is a First Public Working Draft dated 20 August 2024 on the Recommendation track, and MDN marks the API as experimental with limited availability, so keep existing redirect flows as a fallback.
Privacy is designed into each request. Configuration and well-known fetches carry no cookies, the accounts request carries IdP cookies but no client ID or referrer, and the token request needs user interaction and CORS.
IdPs carry most of the security checks. Every credentialed endpoint must require the Sec-Fetch-Dest: webidentity header, check the Origin against the RP registered for the client_id and return explicit, credentialed CORS headers.
OIDC stays underneath. FedCM replaces the browser transport, not the token: the IdP can still issue an OpenID Connect ID token bound to the client ID and nonce, which the RP validates as usual.

What it is and who it applies to

FedCM defines a browser-mediated way to complete federated sign-in, sign-up and reauthentication. The W3C draft names three untrusted parties, the RP, the IdP and trackers, and one trusted party, the user agent. Its stated aim is that trackers cannot use the API to follow users across sites, and that the IdP does not learn which RPs a user visits until the user chooses to sign in.

Who	What FedCM means for them
Identity providers (social login, enterprise and CIAM platforms, national or sector identity schemes)	Publish a well-known file and config file, implement the accounts, ID assertion, client metadata and disconnect endpoints, and signal login status
Relying parties (websites using "Sign in with")	Call the FedCM JavaScript API or an IdP library that uses it, update Content Security Policy and iframe permissions, and keep a fallback
Embedded widgets and iframes	Need the `identity-credentials-get` Permissions Policy feature, granted with `allow="identity-credentials-get"`
Security and privacy reviewers	Assess endpoint validation, token binding, consent text and logout behaviour

Document status and browser availability

W3C: "Federated Credential Management API", First Public Working Draft, 20 August 2024, Federated Identity Working Group. Section 10 lists open issues the group considers critical before Candidate Recommendation, so details can still change.
Chromium browsers (Google Chrome, Microsoft Edge): MDN's browser compatibility data records IdentityCredential in Chrome from version 108, with Edge following the Chromium implementation. Chrome for Developers documents later additions, such as multiple IdPs in one call from Chrome 136 and relaxed account fields from Chrome 141.
Mozilla Firefox: MDN's compatibility data records the Login Status API (navigator.login) in Firefox from version 138.
Cross-browser position: MDN describes FedCM as "Limited availability" and not Baseline, and Chrome's own overview advises RPs to keep their existing federated identity solution for users on other browsers. Check the MDN compatibility table before each release.

Structure and key requirements

The sign-in flow

RP request: the RP calls navigator.credentials.get({ identity: { providers: [ { configURL, clientId, nonce } ] } }), optionally with loginHint, domainHint and a context of signin, signup, use or continue.
Well-known check: the browser fetches /.well-known/web-identity from the IdP's registrable domain (eTLD+1) without cookies, to confirm the config URL belongs to the IdP. Chrome skips this check when RP and IdP are on the same site.
Config file: the browser fetches the config file without cookies or redirects.
Accounts: the browser calls the accounts endpoint with the IdP's cookies but without the client ID, Origin or Referer, so the IdP learns the user is signed in but not which RP is asking.
Client metadata: the browser optionally fetches the RP's privacy policy and terms URLs from the IdP, without cookies.
Account chooser: the browser shows its own dialog with the IdP branding and accounts.
ID assertion: after the user chooses, the browser POSTs client_id, account_id, nonce or params, and disclosure flags to the ID assertion endpoint with cookies and CORS, and returns the IdP's token to the RP.

IdP files and endpoints

Component	Key fields	Request characteristics
Well-known file `/.well-known/web-identity`	`provider_urls`; or `accounts_endpoint` and `login_url` for multiple configs	No cookies
Config file (JSON)	Required: `accounts_endpoint`, `id_assertion_endpoint`, `login_url`. Optional: `client_metadata_endpoint`, disconnect endpoint, `branding` (colours, icons, name)	No cookies, no redirects
Accounts endpoint	`accounts` array: `id` plus at least one of name, username, email or phone; optional picture, `approved_clients`, `login_hints`, `domain_hints`	GET with IdP cookies; no client ID, Origin or Referer; HTTP 401 if not signed in
ID assertion endpoint	Request: `client_id`, `account_id`, optional `params`, `disclosure_text_shown`, `is_auto_selected`. Response: `token`, or `continue_on`, or `error`	POST, form-encoded, IdP cookies, CORS with Origin
Client metadata endpoint	`privacy_policy_url`, `terms_of_service_url`	GET without cookies
Disconnect endpoint	Request: `client_id`, `account_hint`. Response: `account_id`	POST with IdP cookies and CORS

Login Status API

The browser keeps a per-IdP login status of unknown, logged-in or logged-out. The IdP sets it with the Set-Login: logged-in or Set-Login: logged-out response header, or from script with navigator.login.setStatus(), which the W3C draft limits to secure contexts and same-site use. When the status is logged-out, the browser does not call the accounts endpoint at all, which removes a silent tracking signal. If an IdP session has expired, Chrome can open the IdP's login_url so the user signs in, after which the IdP sets the status and calls IdentityProvider.close(). Status entries are cleared when the user clears site data.

Other API features

Disconnect: IdentityCredential.disconnect() lets the RP remove the RP, IdP and account connection the browser holds.
Continuation: the IdP can return continue_on to open a further IdP dialog, for example to request extra permissions, finishing with IdentityProvider.resolve(token).
Errors: the IdP can return an error with an OAuth-style code such as access_denied and a same-site url for more detail.
Permissions Policy: the feature identity-credentials-get has a default allowlist of self; cross-origin iframes must be granted it.

Identity and NHI requirements

FedCM concerns human sign-in in a browser, but it rests on machine identities and trust settings that need the same governance as any other credential.

Client registration: the clientId is issued by the IdP out of band and tied to one or more RP origins. The IdP's Origin check on the ID assertion and disconnect endpoints is only as good as that registry, so manage client registrations with owners, review dates and change control. See the OAuth 2.0 and OpenID Connect Guide.
Token signing keys: the token returned to the RP is usually a signed JWT. Rotate the IdP signing keys, publish them through the JWKS endpoint and validate issuer, audience (the client ID), expiry and nonce on the RP side.
Nonce and replay: the W3C draft describes the nonce as a way to prevent replay. Generate it server-side per attempt and bind it to the RP session.
Session lifecycle: the browser's login status and connected accounts set are not the IdP session. Keep IdP session expiry, logout and the Set-Login header in step.
Logout limits: Chrome's overview notes that some cookie-dependent features such as OpenID Connect Front-Channel Logout do not work when third-party cookies are disabled. Plan back-channel logout instead; see the OpenID Connect Logout and Session Management Guide.

Implementation steps

Identity provider

Publish the well-known file at /.well-known/web-identity on the IdP's registrable domain, served as JSON.
Publish the config file with the three required endpoints and branding icons (Chrome's documentation asks for non-SVG icons of at least 25 pixels in passive mode and 40 pixels in active mode).
Build the accounts endpoint: require Sec-Fetch-Dest: webidentity, match session cookies, return the accounts array or HTTP 401.
Build the ID assertion endpoint: return explicit CORS headers, require Sec-Fetch-Dest: webidentity, check the Origin against the RP registered for the client ID, check the account ID against the signed-in session, then issue a token bound to account, client, issuer and nonce.
Build the disconnect and client metadata endpoints with the same validation.
Signal login status with Set-Login on sign-in and sign-out.
Test in a browser with third-party cookies blocked, then pilot with one RP before general availability.

Relying party

Feature-detect IdentityCredential and fall back to the existing redirect flow where it is absent.
Call the API or the IdP's library option. For example, Google Identity Services documents a use_fedcm_for_button option for its button and FedCM-based One Tap, and lists the Content Security Policy directives and allow="identity-credentials-get" iframe attribute that sites must add.
Validate the token server-side: signature, issuer, audience, expiry and nonce.
Update CSP and iframe permissions, including every nested parent iframe.
Review consent text and privacy notices; Chrome's IdP guide notes that use in the EEA and UK may need consent under ePrivacy rules and leaves the decision to the implementer.
Roll back by switching the library option or feature flag off, leaving the redirect flow in place.

Decision	Choose FedCM-first when	Keep redirect-first when
Embedded sign-in widget or One Tap style prompt	The widget relies on third-party cookies in an iframe	Users mostly arrive on browsers outside the compatibility table
Full-page "Sign in with" button	You want a browser-native account chooser and fewer redirects	Your flow needs complex IdP-side steps not yet covered by continuation
Enterprise single sign-on	The IdP supports FedCM and users use managed Chromium browsers	You depend on front-channel logout or SAML

Evidence and assessment

Configuration evidence: the published well-known and config files, the client registry with origins per client ID, and CSP and Permissions Policy headers on RP pages.
Endpoint tests: requests without Sec-Fetch-Dest: webidentity are rejected; requests with a mismatched Origin are rejected; CORS never returns * with credentials; a logged-out session returns HTTP 401.
Token tests: RP rejects tokens with a wrong audience, expired timestamp, reused nonce or unknown key.
Logs to keep: ID assertion requests by client ID and Origin, rejected requests by reason, disconnect calls and signing key rotations.
Metrics: FedCM success rate versus fallback rate per browser, rejected Origin mismatches, token validation failures, and time from IdP logout to RP session end.

Mapping to other frameworks

FedCM element	Related standard or control
IdP token to RP, assertion binding to client and nonce	OpenID Connect Core ID token validation; NIST SP 800-63C-4 federation assurance (see the NIST SP 800-63C-4 Federation Assurance Levels Guide)
Federated authentication of users	NIST SP 800-53 IA-8 Identification and Authentication (Non-Organizational Users); IA-2
Endpoint origin checks and CSRF protection	NIST SP 800-53 SC-23 Session Authenticity; OWASP ASVS 5.0 session and token requirements
Privacy-preserving design	GDPR Article 25 data protection by design; ePrivacy consent for device access
Session hijacking risk	MITRE ATT&CK T1539 Steal Web Session Cookie; see the Session Hijacking and Cookie Theft Guide

Common pitfalls

Skipping the Origin check: FedCM has no redirect URI to validate, so the IdP's Origin check against the client registry is the RP verification. Chrome's guide calls this out explicitly.
Wildcard CORS: Access-Control-Allow-Origin: * cannot be used with credentials and signals a misunderstanding of the model; return the exact RP origin.
Not requiring Sec-Fetch-Dest: webidentity: the header is a forbidden header that pages cannot set, so requiring it is the IdP's main CSRF defence.
Removing the fallback: limited cross-browser availability means a FedCM-only RP locks out some users.
Forgetting nested iframes: every parent iframe needs allow="identity-credentials-get", or the prompt silently fails.
Stale login status: not sending Set-Login: logged-out at sign-out leaves the browser querying the accounts endpoint and showing stale choices.
Depending on draft details: field names and behaviours have changed between browser versions (for example account fields in Chrome 141 and JSON object token values in Chrome 143); pin tests to current documentation.

Practitioner checklist

Confirm the current W3C draft status and MDN compatibility table before each release.
Publish and monitor the well-known and config files under change control.
Require Sec-Fetch-Dest: webidentity on accounts, ID assertion and disconnect endpoints.
Check Origin against the registered RP origins for every client_id, and review the client registry quarterly.
Return explicit CORS origins with Access-Control-Allow-Credentials: true, never a wildcard.
Bind tokens to account, client ID, issuer and a server-generated nonce, and validate all of them at the RP.
Send Set-Login headers on sign-in and sign-out, and plan back-channel logout.
Keep a redirect fallback and track FedCM versus fallback rates per browser.
Update CSP and iframe permissions and test with third-party cookies blocked.

FedCM: How Browser-Mediated Federated Sign-in Works and How to Deploy It