What is the Federated Credential Management API (FedCM)?

[00:00] Hello fellow developers! [00:01] Today we are going to talk about the Federated Credential Management API, or FEDCM for short. [00:11] FEDCM is a browser-mediated way to handle federated identity. [00:15] and identity federation is a way to delegate user authentication to an identity provider. [00:22] For the users, it means they access multiple applications using just a single set of credentials. [00:29] Think of a "Sign in with" button on a website. [00:32] Whenever a user signs into a site using an account from another site, that's an example of a federated identity flow. [00:41] FEDCM is a proposed browser API that can improve identity federation flow for the users. [00:48] It is designed to provide a more convenient and more private identity federation flow. [00:54] Let's dive in and see how. At its core, FAT-CM is a web API. It allows users to log into websites called Reliant Parties using an account from another website, an identity provider. [01:09] The FATCM API is protocol agnostic, and it operates on a different layer from standards like OAuth or SAML. [01:18] The key innovation of Fetsium is that it puts the browser in the middle. [01:23] The browser serves as a trusted mediator between the user, the reliant party, and their identity provider. This means that before the user data is shared between the parties, the browser steps in and asks for user permission.

[01:38] This gives the user more transparency and control over their data in comparison to using other primitives like iframes or third-party cookies. [01:47] Let's say healthprovider.example is an identity provider who implements FEDCM. [01:53] A website, pharmacy.example, allows users to sign in with their accounts from health provider. [02:00] Let's see how the FATCM flow looks for a user signing on pharmacy.example. [02:07] The user experience will slightly vary depending on the UX mode. [02:11] As of Chrome 147, there are two UX modes in Fatsium. [02:16] active and passive. [02:18] Independent of the mode, FAT CM Flow works without redirects so that users can stay in the context of the same page while signing in. [02:29] Active mode requires a user gesture for FATCM dialog to appear, like clicking a sign in with button. [02:36] After the user interaction, the FATCM dialog will appear even if the user is not signed in to the identity provider. [02:43] Let's have a look at an example. [02:46] Say, the user visits pharmacy.example that uses healthprovider.example as their identity provider. [02:52] the user is signed into their health provider account. In this case, when the user clicks the "Sign in" button, the browser displays a FETCM dialog. [03:02] The dialog prompts the user to sign in to the pharmacy site with the health provider account and states which data health provider will share.

[03:11] If the user chooses to continue, [03:14] This account information will be shared with pharmacy.example. [03:18] Note that there is no top-level redirect or pop-up windows. The login journey happens in the same page context. But what if the user doesn't have an active session with healthprovider.example? [03:32] Because the user is currently not signed in, a pop-up window will appear. [03:37] This pop-up is the login endpoint specified by healthprovider.example. The healthprovider pop-up window is configured to close automatically after the user signs in. [03:49] When the pop-up closes, the user is focused on the pharmacy site again, with the FEDCM dialog displayed. [03:56] Passive mode does not require a user gesture for the FATCM dialog to fire. [04:02] However, the user has to be signed in to the identity provider for the streamlined logging experience. [04:09] Say the user is signed in with healthprovider.example. When the user visits pharmacy.example, [04:16] If FATCM API is called, the browser displays a FATCM dialog. Depending on whether the user already has an account on pharmacy site, the dialog will prompt the user to either sign up or sign in. [04:29] We are currently exploring other UI options. Do you have ideas or feedback? [04:35] Click the link and share them. [04:37] FEDCM offers benefits for everyone involved in the authentication process: users, reliant parties, and identity providers.

[04:47] For users, FATCM in passive mode offers a seamless one-tap sign-in flow that is consistent and recognized by the users across websites. [04:58] Active mode eliminates the need for redirects and allows the user to stay in the same context throughout the sign-in journey. [05:06] It's also resilient to future balance tracking mitigations. [05:09] FAT-CM is a better solution for privacy than conventional identity federation solutions. First, the information is only exchanged between the relying party and the identity provider, after the user explicitly chooses to sign in with the identity provider on the relying party. [05:26] Additionally, the FAT-CM team is experimenting with the so-called delegation model that significantly enhances the privacy property of this API. [05:37] The identity providers who choose to use the delegation model will not be able to know on which relying party the user is signing in. And this is obviously better for user privacy. [05:49] And finally, the FATCM UI helps the users better understand what data is being shared. [05:56] Reliant parties can support a wider selection of identity providers without cluttering their UI with dozens of login buttons. FATCM helps the browser to dynamically show only the accounts that are actually relevant to the user. This means no more static lists of identity providers. And because FATCM makes it easier for the user, Reliant parties also report higher sign-in rates with FATCM experience compared to conventional federated identity flow.

[06:24] And of course, FatCM works even without third-party cookies. [06:28] This means that with FATC and Flow, reliant parties can provide more users with personalized experience on their site. [06:36] And finally, the identity provider. [06:40] FATCM Flow works even where third-party cookies are not available, which means support for more users, for example those who disabled third-party cookies in the browser. [06:51] FEDCM also does not rely on link decorations, which means that it is resilient to any bound-striking mitigations. [07:00] It's a win-win-win situation. [07:03] So! [07:04] What does it take to implement this? [07:06] To enable FATCM, the identity provider needs to create and serve specific endpoints. The actual FATCM API call happens on the ReliantParty side, the website the user is visiting. [07:20] We strongly encourage identity providers to distribute an SDK. [07:25] By having Reliant Parties embed this SDK, the identity provider ensures that all the future updates to the implementation can be managed centrally by the identity provider, without breaking the flow on the Reliant Parties side. In short, to support FEDCM, the identity provider needs to serve a well-known file and a set of specific endpoints. [07:49] The well-known file acts as a map telling the browser where to find the configuration file and the required endpoints.

[07:57] The identity provider also needs to implement the following endpoints: [08:02] an accounts endpoint to list the users' available accounts. [08:06] an ID assertion endpoint which verifies the user and issues a secure token to log them in. [08:14] a login endpoint which handles the sign-in page if the user isn't currently authenticated with the identity provider. [08:21] and the client metadata endpoint to provide branding elements like ReliantPurchase logo or privacy policy to the browser's UI. [08:31] This is just a high-level summary. To dive deeper into technical details and see the code, click the link in the description. [08:40] And that's a quick overview of Fetsium. [08:44] If you want to learn more and get started with an implementation, visit go.gle/fetcm. [08:51] The FATCM team is also working on other exciting updates to the API. Check out the link to our roadmap in the description to learn what's coming. [09:01] And now, happy coding!