Federated Credential Management API is shipping

The Federated Credential Management API (FedCM) is shipping in Chrome 108 (currently on the Beta channel). When it ships in Chrome Stable at the end of November 2022, the FedCM API will work in Chrome without requiring a flag or an origin trial token.

FedCM is a Privacy Sandbox API that provides a use-case-specific abstraction for federated identity flows on the web. FedCM exposes browser-mediated dialogs that allows users to choose accounts from identity providers to login to websites.

Review the latest API changes in the accumulated update page.

We plan to introduce a number of new features based on the feedback we received from identity providers (IdP), relying parties (RP) and browser vendors. While we hope identity providers will adopt FedCM, please be aware that FedCM is still an API under active development and that backward incompatible changes are expected until Q4 2023.

To minimize the challenges of deploying backwards incompatible changes, we currently have two recommendations for identity providers:

  • Subscribe to our newsletter where we will provide updates as the API evolves.
  • We strongly encourage IdPs to distribute the FedCM API via JavaScript SDKs while the API is maturing, and to discourage RPs from self-hosting SDKs. This will ensure IdPs can make changes as the API evolves, without having to ask all of their relying parties to redeploy.

Background

Over the last decade, identity federation has played a central role in raising the bar for authentication on the web, in terms of trustworthiness, ease-of-use (for example, passwordless single sign-in) and security (for example, improved resistance to phishing and credential stuffing attacks) compared to per-site usernames and passwords.

Unfortunately, the mechanisms that identity federation has relied on (iframes, redirects and cookies) are actively being abused to track users across the web. As the user agent isn't able to differentiate between identity federation and tracking, the mitigations for the various types of abuse make the deployment of identity federation more difficult.

FedCM is a multi-step journey to make identity on the web better, and in its first step we are focused on reducing the impact of third-party cookie phase-out on federated identity (see below for what's next).

A user is signing to an RP using FedCM

Chrome has been experimenting with FedCM since Chrome 101.

The Google Identity Services team participated in the origin trial and demonstrated that switching to a more private and secure sign-in process that does not rely on third-party cookies can occur transparently through backward-compatible updates to their existing library. They enabled FedCM across 20 different relying parties and more than 300K users signed in to them during origin trials. Learn more about how they are planning to remove their dependence on third-party cookies.

We're excited to find a lot of common ground with Mozilla, who have been actively engaged in design discussions and started prototyping FedCM in Firefox. Apple has indicated their general support for the specification and is starting to participate in discussions at the FedID CG.

What's next

We are working on landing a number of changes to FedCM.

There are a few things we know that still need to be done, including issues we heard about from IdPs, RPs and browser vendors. We believe we know how to resolve these issues:

  • Cross-origin iframe support: IdPs can call FedCM from within a cross-origin iframe.
  • Personalized button: IdPs can display a returning user's identity on the sign-in button from within a cross-origin iframe.
  • Metrics endpoint: Provides performance metrics to IdPs.

Additionally, there are unresolved issues we are actively exploring including specific proposals that we are evaluating or prototyping:

Finally, there are things we believe still need to be done, based on feedback from Mozilla, Apple and TAG reviewers. We are working to evaluate the best solution for these open questions:

  • Improving user comprehension and matching intent: As Mozilla noted, we'd like to continue exploring different UX formulations and surface areas, as well as triggering criteria.
  • Identity Attributes and Selective Disclosure: As our TAG Reviewers noted, we'd like to provide a mechanism to selectively share more or less identity attributes (such as emails, age brackets, phone numbers, and so on).
  • Raising the Privacy Properties: As Mozilla suggested here, we'd like to continue exploring mechanisms to offer better privacy guarantees, such as IdP blindness and directed identifiers.
  • Relationship with WebAuthn: As suggested by Apple, we are super excited to see the progress on passkeys and to work on providing a coherent and cohesive experience between FedCM, Passwords, WebAuthn and WebOTP.
  • Login Status: As Apple suggested with the Privacy CG's Login Status API, we share the intuition that the user's login status is a useful bit of information that can help browsers make informed decisions, and we are excited to see what opportunities arise from that.
  • Enterprises and Education: As is clear at the FedID CG, there are still a lot of use cases that are not well served by FedCM that we'd like to work on, such as front-channel logout (the ability for an IdP to send a signal to RPs to logout) and support for SAML.
  • Relationship with mDLs, VCs, and others: Continue working to understand how these fit within FedCM, for example with the Mobile Document Request API.

Resources