This page explains the [benefits](https://developer.chrome.com/docs/identity/fedcm/overview#benefits) of FedCM, [who should consider implementing FedCM](https://developer.chrome.com/docs/identity/fedcm/overview#who)
and how [users interact with FedCM](https://developer.chrome.com/docs/identity/fedcm/overview#user-interaction).

**Federated Credential Management (FedCM)** is a privacy-centric and
user-friendly approach to federated identity services (such as **Sign in with Identity Provider**)
that doesn't rely on third-party cookies or navigational redirects.
[Video](https://www.youtube.com/watch?v=4AAiTP1B8wA)

With FedCM, the user is provided with a [new way to authenticate](https://developer.chrome.com/docs/identity/fedcm/overview#user-interaction)
with a third-party identity provider on a website.

## What is identity federation

Identity federation delegates authentication or authorization of an individual
(user or entity) to a trusted external identity provider (IdP). The IdP then
allows the individual to sign in to a relying party website (RP). With identity
federation, an RP relies on an IdP to provide the user an account without
requiring a new username and password.

With federated identity solutions, the user doesn't have to create another set
of credentials for every RP. This improves user experience, reduces the chances
of phishing, and helps the RP to acquire verified user information from trusted
identity providers.

### Conventional solutions and third party cookies

Conventional identity federation mechanisms rely on iframes, redirects or
third-party cookies, causing privacy concerns. These solutions can be exploited
for tracking users across the web, and browsers aren't able to distinguish
between legitimate identity services and unwanted surveillance.

With the privacy concern in mind, major browsers are restricting third-party
cookies. This may affect some functionalities. Through community effort and our
research, we learned there are a few identity [federation related integrations](https://github.com/fedidcg/use-case-library/wiki/Primitives-by-Use-Case)
that are affected by third-party cookie restrictions.

### Identity federation with FedCM

FedCM is protocol-agnostic: it can be implemented as a standalone solution or as
an additional layer that different protocols can take advantage of. For example,
a functional [OAuth](https://github.com/aaronpk/oauth-fedcm-profile) server can
benefit from the FedCM's browser-mediated one-tap login experience and intuitive
UI by implementing FedCM endpoints and then [exchanging](https://github.com/aaronpk/oauth-fedcm-profile?tab=readme-ov-file#exchange-the-authorization-code)
the authorization code returned in FedCM's response for an OAuth access token.

## Why do we need FedCM?

Compared to conventional solutions, it offers multiple benefits for the web
ecosystem, designed with the user, the RPs and IdPs developers in mind.

### Support for identity solutions without third-party cookies

FedCM can help reduce reliance on third-party cookies, which are often used to
track users across the web. The API offers a personalized sign in experience
even when third-party cookies aren't available (for example, in the Incognito mode).

FedCM is also integrated with other Privacy Sandbox APIs. For example, the
Storage Access API uses FedCM authentication as a [trust signal](https://privacysandbox.google.com/cookies/storage-access-api#fedcm).
This integration is useful for the websites that rely on both FedCM for
authentication and the SAA to enable cross-origin iframes to access necessary
storage.

### Improved user experience

FedCM introduces a browser-mediated UI dialog for a simplified one-tap login
process. The API also addresses the issue of cluttered login pages, sometimes
called the [NASCAR problem](https://indieweb.org/NASCAR_problem).
![Example of the NASCAR problem: A website with a cluttered UI caused by a selection of seven different sign-in options.](https://developer.chrome.com/static/docs/identity/fedcm/overview/assets/FEDCM-NASCAR-problem.jpg) Example of the NASCAR problem: A website with a cluttered UI caused by too wide IdP selection.

Instead of an overwhelming number of social login buttons, FedCM provides [a simpler user-friendly interface](https://developer.chrome.com/docs/identity/fedcm/overview#user-interaction).

### Security

The Federated Identity approach enables users to use trusted accounts managed by
IdPs. With this approach, users don't have to add credentials to every site.
This reduces the surface for phishing attacks. Additionally, instead of
implementing their own robust security measures, RPs can rely on the expertise
of IdPs who specialize in secure identity management.

FedCM aims to make the federated identity flow even more convenient for users,
encouraging them to prefer it over less secure identity flows.

### Personalized experience for more users

FedCM reduces UX friction during the account sign up flow. Google Identity
Service's [case studies](https://developers.google.com/identity/sign-in/case-studies)
show that users prefer creating accounts with FedCM's One Tap flow over
multi-step sign-in options.

With FedCM, more IdPs can offer their users a one-tap sign-in experience. With
more IdPs offering a one-tap identity flow, users can choose from a wider
selection of IdPs on RPs. FedCM provides an improvedIdP selection mechanism by
presenting the users with [most relevant accounts](https://developer.chrome.com/docs/identity/fedcm/implement/identity-provider#accounts-list-endpoint).

With higher signup rates, RPs can offer personalized experience to more users.

### Support for diverse Identity Providers

FedCM's simplified UI aims to present users with a personalized list of the
[relevant IdPs](https://developer.chrome.com/docs/identity/fedcm/implement/identity-provider#accounts-list-endpoint). With FedCM's
IdP selection mechanism, RP's choice of IdPs is no longer restricted by how
large the IdP's user base is. For example, a portion of users may have an
account only with `small-idp.example`, and not with `bigger-idp.example`.

With the Multi-IdP feature, `rp.example` can support both `small-idp.example`
and `bigger-idp.example` without cluttering the UI. This benefits all of the
parties:

- Users can choose their preferred IdP, no matter how big or small.
- RPs reach more users through diverse IdP support
- IdPs with a smaller user base are available on more RPs.

## Who should use FedCM?

We expect FedCM to be useful to you only if these conditions apply:

- You're an identity provider (IdP) with third-party RPs.
- You have your own identity solution and multiple domains relying on it.
- You aim to support federated identity flows even for users who opt for browsing without third-party cookies.

### You're an IdP

FedCM requires support from an identity provider. A relying party cannot use
FedCM independently. If you are an RP, you can ask your IdP to provide
instructions.

### Multiple RPs

If your RPs are third-party, or you have more than four RPs using your identity
solution, FedCM is the recommended API for federated identity.

### You aim to support cookieless identity federation flow

FedCM supports essential federated identity flows even for users who browse
without third-party cookies. With FedCM, users can still sign-up,
sign-in and sign-out with their federated accounts on RPs.

> [!NOTE]
> **Note:** Some of the features (for example, [OpenID Connect Front-Channel Logout](https://openid.net/specs/openid-connect-frontchannel-1_0.html)) that rely on cookies are not yet supported by FedCM when third-party cookies are disabled in the browser. We're committed to making FedCM work for more users. We're exploring ways to address other limitations.

Additionally, FedCM serves as a [trust signal](https://privacysandbox.google.com/cookies/storage-access-api#fedcm)
for Storage Access API, eliminating friction for IdP-initiated storage access requests.

## User interaction with FedCM

FedCM is designed to be authentication protocol-agnostic and offers the user a
new flow to authenticate to an RP with a third-party IdP.
Try FedCM with our [demo](https://github.com/privacysandbox/privacy-sandbox-web-playbook/tree/main/fedcm/fedcm-rp-demo).

> [!NOTE]
> **Note:** FedCM is not yet supported by all browsers. RPs should still maintain their existing non-FedCM federated identity solutions to support users on all the browsers.

### Sign in to a relying party

Users can choose an account from a set of IdPs supported by the RP. If the user
is logged in with multiple IdPs, they will be prompted to sign in to the RP
using one of them.

The user's accounts are displayed in the following order:

- Accounts accessed on the user's device are shown first, with the most recently accessed accounts coming first.
- Accounts that have been accessed by the user on the RP according to the IdP are shown next. The information about which accounts have been accessed is extracted from the `approved_clients` [account endpoint](https://developer.chrome.com/docs/identity/fedcm/implement/identity-provider#accounts-list-endpoint) property value.
- Accounts that have not been used on the RP before are shown last.

If there are multiple accounts within any of these priority tiers, these
accounts are further ordered based on the order of IdPs provided by the RP in
the [`get()` call](https://developer.chrome.com/docs/identity/fedcm/implement/relying-party#call_fedcm_api_on_the_relying_party).

### FedCM UI modes

FedCM has two UI modes: **Passive** and **Active**.

**Passive mode** . Passive mode doesn't require user interaction for the FedCM
prompt to appear. When the user lands on the relying party (RP) website, a FedCM
sign-in dialog will appear when `navigator.credentials.get()` is called if the
following conditions are met:

- The user is signed in to at least one of the supported IdPs. If the user's status is logged-out for all the available IdPs, the FedCM sign-in prompt is not shown automatically.
- The [FedCM cooldown setting](https://developer.chrome.com/docs/identity/fedcm/customization#cooldown) is not set in the user's browser.
- The user did not [disable FedCM in their browser settings](https://developer.chrome.com/docs/identity/fedcm/customization#user-controls). Learn more about how users can opt out of FedCM.

The user sequentially authenticates with different IdPs in passive mode: signing in and out with one, then authenticating with the next.

**Active mode** . In active mode, a transient user activation (such as **Sign in
with...** button click) is required to trigger a FedCM prompt.
A user signs into an RP using FedCM in active mode.

The user can complete sign in by tapping **Continue as user**. If successful,
the browser stores the fact that the user has created a federated account on the
RP with the IdP.

> [!NOTE]
> **Note:** Active mode is not supported with multiple identity providers. Only specify one provider when opting into active mode.

If the user doesn't have an account on the RP with the IdP, a sign-up dialog
appears with additional disclosure text such as the RP's terms of service and
privacy policy.

> [!CAUTION]
> **Caution:** The sign-in dialog enables users to sign in to an RP with their federated account, but shouldn't be relied upon as a consent under ePrivacy and data protection laws in the European Economic Area (EEA) and the UK. If you determine you need user consent under these laws for some of your data processing, (which could be because you are using API data for purposes beyond authentication, for example showing personalized ads to users), you must obtain that consent separately from the FedCM dialog.

## Compliance with ePrivacy laws

Using FedCM, either as an IdP or an RP, involves the storage of information on a
user's terminal equipment or access to information already stored in it, and is
therefore an activity subject to ePrivacy laws in the European Economic Area
(EEA) and the UK generally requiring user consent. It is your responsibility to
determine whether your use of FedCM is **strictly necessary** to provide an
online service explicitly requested by the user, and therefore exempt from the
consent requirement.

## Vision

We are actively developing new features to address current limitations and offer
better user experience.

- We are exploring quieter UX formulations to ensure a smooth, intuitive and less intrusive authentication process for the users.
- We are dedicated to improving user privacy. We plan to transition to the delegation-oriented NextGen FedCM model that mitigates the IdP Tracking Problem. With NextGen, users can login on RPs without the IdP following the user.
- FedCM aims to present users with a wider selection of IdPs, based on the RP's choice. To achieve this, we're working on the Multi-IdP and the IdP Registration APIs.
- We are actively working to integrate FedCM with other authentication methods like Passkeys with additional means such as Autofill to introduce a unified authentication experience.

See our [roadmap](https://developer.chrome.com/docs/identity/fedcm/updates#roadmap) for more detail.