How does FedCM work and how do I use it?

FedCM (Federated Credential Management) is the browser API behind the “Continue as Jane” prompts that appear on some sites, including Google One Tap in Chrome. Your site asks the browser for a sign-in with an identity provider. The browser talks to the provider, draws the prompt and hands your page a token.

Until the person continues, your site learns nothing about them, and the provider can’t tell which of its users is on your site. FedCM is a draft standard of the W3C Federated Identity Working Group, and Chrome has shipped it since version 108, in 2022.

Why does FedCM exist?#

FedCM exists because federated sign-in used to rely on the same tools that trackers use. Sign-in buttons and one-tap prompts ran in iframes from the provider’s domain, which read the provider’s cookies as third-party cookies. Third-party cookies let embedded content follow people across sites, so browsers restrict them:

• Safari blocks third-party cookies by default.
• Firefox gives each site its own cookie jar (Total Cookie Protection).
• Chrome blocks them in Incognito and for people who turn them off. Google planned to remove them for everyone, then decided in 2024 and 2025 to leave the choice to users. In October 2025, Google said it keeps supporting FedCM.

FedCM replaces the iframe with the browser itself. The browser fetches the provider’s endpoints and draws its own prompt. No request carries both the provider’s cookies and your site’s origin until the person has agreed. Sign-in keeps working where third-party cookies don’t, and the browser can tell a real sign-in from tracking.

Who does what in FedCM?#

FedCM has three parties:

• The relying party (RP) is your site. It has a client ID from the provider and calls the API.
• The identity provider (IdP) holds the accounts, like Google or loginos. It serves a few JSON endpoints that only the browser calls.
• The browser fetches those endpoints, draws the prompt and enforces the privacy rules.

A sign-in runs in six steps:

1. Your page calls navigator.credentials.get() with the IdP’s config URL and your client ID.
2. The browser checks the IdP’s login status. If the IdP said nobody is signed in, a page-load call stops here without any request.
3. The browser fetches the IdP’s well-known file and config file without cookies. Then it fetches the accounts endpoint with the IdP’s cookies, but without saying which site is asking.
4. The browser shows the prompt over your page. Your page sees nothing.
5. When the person continues, the browser posts to the IdP’s ID assertion endpoint, now with your origin and client ID, and gets a token back.
6. Your page receives an IdentityCredential. It sends credential.token to your server, which validates it.

What does the identity provider serve?#

A FedCM identity provider serves a set of endpoints, and the browser treats each one differently:

The well-known file sits at the root of the IdP’s registrable domain, while the config file can live anywhere. The two-step lookup stops an IdP from putting your site’s name in the config URL to track people. The file lists the config file in provider_urls. An IdP with a client metadata endpoint must also name its accounts_endpoint and login_url there:

{
  "provider_urls": ["https://accounts.idp.example/fedcm/config.json"],
  "accounts_endpoint": "https://accounts.idp.example/fedcm/accounts",
  "login_url": "https://accounts.idp.example/login"
}

Every FedCM request carries Sec-Fetch-Dest: webidentity. Pages can’t set headers that start with Sec-, so the header shows that the browser’s FedCM code sent the request, not a script on another site. Check it on the accounts, ID assertion and disconnect endpoints, and refuse requests without it.

The ID assertion endpoint is where the IdP decides. It gets a form post with the page’s origin:

POST /fedcm/assertion HTTP/1.1
Host: accounts.idp.example
Origin: https://rp.example
Cookie: idp_session=…
Content-Type: application/x-www-form-urlencoded
Sec-Fetch-Dest: webidentity

client_id=your-client-id&account_id=1234&is_auto_selected=false&params=%7B%22nonce%22%3A%228f2c1a%22%7D

The IdP must check that the Origin belongs to that client ID, because the browser can’t: client IDs mean nothing to it. It answers with JSON like {"token": "…"} and the CORS headers Access-Control-Allow-Origin: https://rp.example and Access-Control-Allow-Credentials: true. The token can be anything the IdP likes, such as an ID token or a one-time code. Instead of a token, the IdP can return an error, or a continue_on URL that the browser opens in a popup for extra steps.

The Login Status API tells the browser whether anyone is signed in to the IdP. The IdP sends Set-Login: logged-in or Set-Login: logged-out on its own responses, or calls navigator.login.setStatus() on its pages. While the status is logged-out, the browser skips the accounts request and a page-load call fails quietly. A call from a click opens the IdP’s login_url in a small window instead, and the sign-in page calls IdentityProvider.close() when it is done.

How does a site call FedCM?#

A site calls FedCM with one navigator.credentials.get() call. Check for support first, because only some browsers have it:

async function signInWithFedCM(nonce) {
  if (!("IdentityCredential" in window)) return null; // use a popup or a redirect instead
  return navigator.credentials
    .get({
      identity: {
        context: "signin",
        providers: [{
          configURL: "https://accounts.idp.example/fedcm/config.json",
          clientId: "your-client-id",
          params: { nonce }, // random, from your server, checked there again
        }],
      },
      mediation: "optional",
    })
    .catch(() => null); // closed, or nobody signed in
}

These options shape the prompt:

• mode: "passive", the default, can run on page load and shows nothing when the person isn’t signed in to the IdP. "active" must run from a click, takes exactly one provider, shows a larger dialog and can open the IdP’s sign-in window. Chrome added mode in version 132; before that it called these the widget and button modes.
• mediation: "optional", the default, lets the browser sign a returning person in by itself. "silent" does that or fails without any UI, and "required" always asks.
• context: "signin", "signup", "use" or "continue" changes the prompt’s wording.
• loginHint and domainHint show only the accounts that match.
• params: whatever the IdP needs, like a nonce. The spec moved nonce here, and the old top-level nonce is deprecated.

Automatic sign-in, called auto-reauthentication, only happens for someone who signed in to your site with FedCM before and has one returning account. The credential then has isAutoSelected set to true, and Chrome does it at most once every 10 minutes. When someone signs out of your site, call navigator.credentials.preventSilentAccess(), so the browser doesn’t sign them straight back in. IdentityCredential.disconnect({ configURL, clientId, accountHint }) removes the connection entirely. In Chrome 136 and later, a passive call can list several providers, and the browser shows all their accounts in one prompt.

Which browsers support FedCM?#

As of October 2026, FedCM works in Chromium-based browsers only:

Newer parts arrived later in Chrome: the Login Status API in version 120, disconnect() in 122, mode and params in 132, and several providers in one call in 136. Treat FedCM as an addition: keep a popup or redirect sign-in for browsers without it. MDN’s FedCM page tracks support in detail.

How loginos does it#

loginos is a FedCM identity provider. It serves the provider side for you: the well-known file, a config file at https://loginos.io/fedcm/config.json, the accounts, client metadata, ID assertion and disconnect endpoints, and the login status. Its ID assertion endpoint only answers pages on your platform’s domains, and the token it returns is a one-time code. Your server exchanges that code at /oauth/token like a code from the redirect flow, without redirect_uri.

You don’t call FedCM yourself. The browser SDK makes the calls and adds a fallback for other browsers:

signOut() calls preventSilentAccess(), and disconnect() calls IdentityCredential.disconnect(). The SDK sends the nonce both in params and at the top level, so older Chrome versions work too.

<script src="https://loginos.io/sdk/v1.js"></script>
<script>
  const loginos = Loginos.init({ appKey: "YOUR_APP_KEY" });
  const finish = (result) =>
    result &&
    fetch("/api/auth/login/single/token", {
      method: "POST",
      headers: { "content-type": "application/json" },
      body: JSON.stringify(result), // { code, nonce, via }
    });
  loginos.prompt().then(finish);
  document.querySelector("#sign-in").onclick = () => loginos.signIn().then(finish);
</script>

The Continue as docs have the server route that checks the ID token’s nonce, and How do I add a one-tap “Continue as” login? covers testing and the headers that break the window. loginos offers loginos accounts only. If people should sign in with their Google or Microsoft accounts, you need those providers, and if you want to be the identity provider yourself, the endpoints above are what you build.

Frequently asked questions#

Does FedCM replace OAuth and OpenID Connect?#

No. FedCM replaces the browser part of a sign-in: the redirect or the iframe becomes a prompt the browser draws. What the token is, and how your server checks it, is still up to the identity provider. Google One Tap returns an ID token, for example, while loginos returns a code that your server exchanges with standard OpenID Connect.

Does FedCM need third-party cookies?#

No. The browser sends the identity provider’s cookies only to the provider’s own FedCM endpoints, so FedCM works when third-party cookies are blocked. The provider’s session cookie must be SameSite=None, because these requests start from another site.

Is FedCM only for Google accounts?#

No. Google One Tap uses it in Chrome, but any identity provider can serve the endpoints. Seznam, a Czech internet company, offers its accounts through FedCM, and loginos does too. A site can only use a provider that has given it a client ID.

Can I use FedCM inside an iframe?#

Yes, if the parent page allows it. FedCM is a policy-controlled feature named identity-credentials-get, and by default only same-origin frames may use it. Add allow="identity-credentials-get" to a cross-origin iframe that needs it.