FedCM, or Federated Credential Management, is a web standard being developed by the W3C to create a more secure and privacy-conscious way for users to log into websites using third-party identity providers.
Think of it as a browser-based counterpart to the “Sign in with Google” buttons you see everywhere. FedCM is built directly into the browser itself rather than relying on cookies and redirects.
The core problem FedCM addresses is that traditional federated login methods, such as SAMLv2 and OpenID Connect (OIDC), depend on technologies like third-party cookies and iframes that also enable advertisers and other parties to track users across the entire web. With browsers increasingly blocking third-party cookies to protect user privacy, there’s a real risk that legitimate federated login flows will break.
The magic of FedCM lies in how it uses native browser APIs to mediate the authentication process between a website (called the “relying party” or RP), an identity provider (termed “IdP” and a software or service like Google or FusionAuth), and the user. Instead of bouncing users through redirects and hoping cookies work, the browser presents a native UI prompt asking the user which account they want to use to log in.
On subsequent logins, if the user has previously authenticated and has only one account, they can be automatically signed back in without ever leaving the original website—no redirects, no popups, just a seamless experience. The browser controls what information gets shared with each party at every step, preventing the kind of tracking that makes privacy advocates nervous while still enabling federated login.
While FedCM shows real promise and is already supported in Chrome and Edge (which together represent a majority of desktop browser traffic), this is still a work in progress. The W3C working group published a working draft in August 2024, but there’s substantial work remaining before it becomes a finalized standard. You can review the current editor’s draft which is actively being updated.
Safari doesn’t support FedCM yet. Firefox was active in the effort but paused implementation in August 2025. But some identity providers, including Google, have started adopting it. If you’re using “Sign in with Google” through the Google Identity Services library, you’re likely already using FedCM without realizing it. FusionAuth does not support it, but there is an open tracking issue.
For developers and identity providers, the takeaway is clear: FedCM matters and is worth watching, but for now, you’ll need to maintain fallback methods for browsers that don’t support it or users who disable it.
User Experience
The user’s experience of FedCM varies depending on how it is configured and whether the user has logged into a given IdP before, but here is an example of what a user sees when they are prompted to log in by FedCM:
You can experience it yourself if you have a Google account by visiting Booking.com in a Chrome browser. Let’s dig a bit more into a typical authentication flow and how FedCM changes it.
FedCM Authentication Flows
Below, you’ll see the differences between the flow of the browser requests and the user journey with a traditional redirect flow, such as OIDC, and with FedCM.
Login Flows With Redirect Based Approaches
Here is the first time a user logs in with the redirect based workflow, such as OIDC.
The first time a user logs in with the redirect based workflow.
The second time the user logs in, they are bounced to the IdP. But they don’t see a login form since their cookies are valid.
The second time the user logs in, they are bounced to the IdP.
Login Flows With FedCM
The experience the first time the user logs in with FedCM depends on the particulars of the relying party request, but typically the IdP prompts for login credentials with an iframe.
This diagram shows the flow of the “passive” mode, which requires minimal user interaction. There are other modes, but this is the option that reduces friction the most.
The first time flow of the passive mode, which requires minimal user interaction.
Once a token is received by the browser in step 12, the FedCM portion of the flow is complete. There may be more for the RP to do, such as receive the token from the browser and validate it.
With the passive mode, the second time a user logs in with FedCM is really where the magic happens.
When the user has previously used FedCM and has no more than one account, they are not prompted to log in and are instead auto-reauthenticated without leaving the RP:
The second time flow of the passive mode, no user interaction occurs.
While the focus of FedCM is authentication, the authors of the specification have considered related use cases, including:
- when multiple accounts on a given device have logged in to an IdP
- invalid user accounts
- when a user has signed out of the relying party but not out of the identity provider
- if a user has recently signed out
Learn More
If you’d like to learn more about FedCM, check out:
- an in-depth article on FedCM which includes a history, more details about support, and example code
- an on-demand webinar with one of the spec contributors
- a public working draft from 2024 and the current editors working draft
- the W3C working group, which you can join and where you can contribute
