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.
Check the final API changes in the accumulated update page.
If you are participating in the FedCM origin trial, please note that the trial is scheduled to end on November 22nd, which is slightly earlier than Chrome 108 ships.
Moving forward, 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.
The Federated Credential Management API (FedCM)
provides a use-case-specific abstraction for federated identity flows on the
web, by exposing a browser mediated dialog that allows users to choose accounts
from IdPs to login to websites.
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 a few steps
further).
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 are also 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:
- CORS: We are discussing with Apple and
Mozilla to ensure to improve
the specification of FedCM fetches. - Multiple-IdP API: We are exploring ways to support multiple
IdPs to coexist cooperatively
in the FedCM account chooser. - IdP Sign-in Status API: Mozilla has identified a timing attack
issue, and we are exploring
ways for an IdP to proactively
notify the browser of the user’s sign-in status
to mitigate the issue. - Sign in to IdP API: To support various
scenarios, when a user is not
signed in to the IdP, the browser provides a UI for the user to sign in
without leaving the RP.
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
- Try the FedCM demo.
- If you are an IdP and interested to learn how to implement FedCM, read
the developer guide.
If you are a relying party, ask your IdP if they plan to implement FedCM. - We’ve also accumulated FedCM API updates at the
Federated Credential Management API updates. - If you have feature requests, feedback or issues, file them against the
FedCM public repository on GitHub.
This post is also available in:
English