Federated Credential Management API updates

The Federated Credential Management API is shipped in Chrome 108 but it's expected to continue evolving. There are no breaking changes planned.

Who are these updates for?

These updates are for you if:

  • You are an IdP using the Federated Credential Management API.
  • You are an IdP or RP and interested in extending the API to fit your use case – e.g. you've been observing or participating in the discussions on the FedID CG repository and want to understand the changes made to the API.
  • You are a browser vendor and you want to catch up on the implementation status of the API.

If you're new to this API or have not experimented with it yet, read the introduction to the Federated Credential Management API.

Changelog

To stay updated on the FedCM API changes, check out our blog or the newsletter.

Chrome 131 (October 2024)

Chrome 125 (April 2024)

Chrome 123 (February 2024)

  • Added support for the Domain Hint API. The Domain Hint API allows RPs to specify a domainHint property on a FedCM API call to show only matching accounts for the user.

Chrome 122 (January 2024)

Chrome 121 (December 2023)

  • The relaxed condition for triggering FedCM auto-reauthentication:
    • The auto-reauthentication feature in FedCM is only triggered when the user is returning. This means the user needs to sign in to the RP using FedCM once on every browser instance, before auto-reauthn can be triggered. This condition was initially introduced to mitigate the risk of trackers pretending to be an identity provider (IdP) and tricking the browser into auto-reauthenticating a user without their knowledge or agreement. However, this design cannot guarantee the privacy benefit if the tracker has access to third-party cookies on the RP context. FedCM provides only a subset of the capabilities possible via third-party cookies, so if the tracker already has access to third-party cookies on the RP context, access to FedCM presents no additional privacy risk.
      Since there are legitimate uses of third-party cookies and relaxing the condition would improve the UX, this behavior is changing from Chrome 121. We have decided to relax the restriction of the condition to treat a user as returning: if third-party cookies are available to the IdP on the RP context, Chrome will trust the IdP's claim about user's account status specified via the approved_clients list and trigger auto re-authentication if applicable. Third-party cookies can be available through: user settings, enterprise policies, heuristics (Safari, Firefox, Chrome) and other web platform APIs (such as Storage Access API). Note that when the IdP loses third party cookies access in the future, if a user has never explicitly granted permission on the FedCM UI (for example, clicking the Continue as button) before, they will still be treated as a new user.
      There are no developer actions required. Note that auto-reauthn flow could be triggered more with this change if the IdP has third-party cookies access and claims that the user has created an account on the RP in the past.

Chrome 120 (November 2023)

  • Added support for following three features in Chrome 120:
    • Login Status API: The Login Status API is a mechanism where a website, especially an IdP, informs the browser its user's login status. With this API, the browser can reduce unnecessary requests to the IdP and mitigate potential timing attacks. The Login Status API is a requirement for FedCM. With this change, the chrome://flags/#fedcm-without-third-party-cookies flag is no longer required to enable FedCM when third-party cookie is blocked.
    • Error API: The Error API notifies the user by showing a browser UI with the error information provided by the IdP.
    • Auto-Selected Flag API: The Auto-Selected Flag API shares whether an explicit user permission was acquired by tapping on the Continue as button with both the IdP and RP, whenever auto-reauthn occurred or an explicit mediation occurred. Sharing only happens after user permission is granted for IdP and RP communication.

Chrome 117 (Sep 2023)

Chrome 116 (Aug 2023)

  • Added support for following three features in Chrome 116:
    • Login Hint API: Specify a preferred user account to be signed in.
    • User Info API: Fetch the information of the returning user so that the identity provider (IdP) can render a personalized sign-in button within an iframe.
    • RP Context API: Use a title different from 'Sign in' in the FedCM dialog.
  • Origin Trial for IdP Sign-In Status API is available. Learn more about it in FedCM updates: IdP Sign-In Status API, Login Hint, and more.

Chrome 115 (June 2023)

  • Added support for auto-reauthentication which let users reauthenticate automatically when they come back after their initial authentication using FedCM. This improves the user experiences and enables a more streamlined reauthentication to the RP after the initial authentication. Learn more about FedCM auto-reauthentication.

Chrome 110 (February 2023)

  • For the ID assertion endpoint, IdPs need to check the Origin header (instead of the Referer header) to see if the value matches the origin of the client ID.
  • Cross-origin iframe support for FedCM is now available. The embedder should specify the Permissions-Policy identity-credentials-get to allow FedCM API in the embedded cross-origin iframe. You can check out an example of the cross-origin iframe.
  • Added a new Chrome flag chrome://flags/#fedcm-without-third-party-cookies. With this flag, you can test FedCM functionality in Chrome by blocking third-party cookies. Learn more from the FedCM documentation.

Chrome 108 (October 2022)

  • "top-level manifest" is now called "well-known file" in the document. No implementation changes are required.
  • "IdP manifest" is now called "config file" in the document. No implementation changes are required.
  • The id_token_endpoint in the "config file" is renamed to id_assertion_endpoint.
  • The requests to IdP now include a Sec-Fetch-Dest: webidentity header instead of a Sec-FedCM-CSRF: ?1 header.

Chrome 105 (August 2022)

  • Added important security information to the document. The identity provider (IdP) needs to check if the Referer header matches the origin the RP registered in advance on the ID token endpoint.
  • The top-level manifest is renamed from /.well-known/fedcm.json to /.well-known/web-identity and the URL specified in provider_urls should include the file name.
  • Methods login(), logout() and revoke() on FederatedCredential instances are no longer available.
  • The Federated Credential Management API now uses a new type IdentityCredential instead of FederatedCredential. This can be used for feature detection but is otherwise a largely invisible change.
  • Move login functionality from a combination of navigator.credentials.get() and FederatedCredential.prototype.login() to navigator.credentials.get().
  • The revocation endpoint in the manifest is no longer in effect.
  • Use an identity field instead of a federated field for navigator.credentials.get() calls.
  • url is now configURL and must be the full URL for the manifest JSON file instead of the path for a navigator.credentials.get() call.
  • nonce is now an optional parameter for navigator.credentials.get().
  • hint is no longer available as an option for navigator.credentials.get().
const credential = await navigator.credentials.get({
  identity: {
    providers: [{
      configURL: 'https://idp.example/anything.json',
      clientId: '********',
      nonce: '******'
    }]
  }
});
const { token } = credential;

Chrome 104 (June 2022)

Chrome 103 (May 2022)

  • Supports desktop environments.
  • Supports per-RP settings on desktop.
  • The client metadata endpoint is now optional. In this endpoint, the privacy policy URL is also optional.
  • Added a caveat about using CSP connect-src in the document.

Resources