FedCM：一种新的身份认证标准，或将改变我们在网络上的登录方式

联邦凭证管理（federalcredential Management，FedCM）API 是一个提议中的 Web 规范，可能会影响几乎所有通过浏览器登录应用程序的人。FedCM 在 W3C 内部开发，旨在通过引入浏览器原生的方式来处理联合登录，从而创建一个更加保护隐私的 Web。当一个应用程序将登录过程委托给另一个称为身份提供者的应用程序时，就会发生联合登录。

FedCM 最初的动机是为联合登录提供更好的基础，并得到浏览器的支持。与一般用途的 Web 原语（如重定向、iframe 和第三方 cookie）不同，部分原因是这些原语也被广告商用来在网络上追踪用户，开发者可以使用原生 API。虽然谷歌Chrome将阻止第三方cookies的决定权交给了用户，但其他浏览器仍然默认阻止所有或大多数第三方cookies。

FedCM 专注于用户隐私，并利用浏览器的原生 UI 元素，旨在构建一个更加一致和安全的登录体验，并解决没有浏览器功能就无法解决的问题。这些问题包括可用的身份提供者太多（NASCAR 标志问题）和发现身份提供程序。

如果你使用第三方社交提供商登录 Web 应用程序，你可能很快就会使用到 FedCM。大多数使用“使用谷歌登录”和谷歌身份服务库的开发者都在使用 FedCM；该库在2024年更新为使用此API。

Web 应用登录的历史

虽然最早的网站是静态页面，但向不同用户提供不同内容的价值很快导致了在显示内容之前进行身份验证。Web 应用程序开始添加身份验证。这种方法将用户数据隔离开来，要求他们在应用程序之间重新输入凭据，并给每个应用程序增加了安全负担。

1994 年，Netscape Navigator 团队发明了使用中央认证服务器的基于 cookie 的登录；这解决了单服务器认证的一些问题。然而，这种解决方案是有限的，因为 cookie 不会在域之间共享。这种分离是网络安全模型的关键组成部分。虽然嵌入式 iframe 可以绕过这个问题，但它们存在安全问题，尤其是点击劫持。

随着 2002 年 SAML 1.0 的发布，第一个基于重定向的标准化登录流程得以实施。SAML 使用重定向和签名 XML 文档确保用户已经通过身份验证，从而允许应用程序安全地委托认证过程。其他研究同一问题的团队修订了 SAML，2.0 版本在 2005 年发布。

OAuth 和 OIDC 在 2012 年至 2014 年期间发布，并更新了 SAML 的格式和机制，但利用了相同的重定向和签名文档方法。目前，大多数应用程序要么将认证嵌入到应用程序中，接受 1990 年代类型的安全和实现问题，要么与中央身份验证服务器联合。这种中央认证服务器可能并不托管在与原始应用程序相同的域上。因此，因此，如果没有第三方 cookie，诸如基于静默 iframe 的刷新或 JavaScript 请求等认证功能可能会失败。但是，第三方 cookie 也允许广告商和平台在网络上追踪用户。用户可以在整个互联网上被追踪，捕获不同站点和应用程序的行为。

OIDC 和 SAML 使用的基于重定向的机制也导致了上述提到的 NASCAR 标志问题。网站必须枚举它们支持的身份提供者。由于页面上的空间有限，这有利于少数大型提供者，从而阻碍了应用程序允许用户选择自己的身份提供商。保护用户隐私和通过浏览器提供更好的用户体验的目标导致了 FedCM 项目。让我们来看一下这个项目的时间线。

联邦凭证管理时间线

在谷歌和 Chrome 团队推广的第三方 cookie 更改的背景下，审查 FedCM 工作是很重要的。在谷歌宣布网络隐私重要性之后不久，该项目的工作就开始了。

第一个提交到将成为联合身份管理存储库的存储库是在2020年 3 月（最初被称为 WebID）。W3C 社区组在2021年开始，工作组成立于2024年。（社区组孵化想法，工作组发布建议）。

在2022年，该项目由谷歌员工引入 Firefox。它被认为是一个积极的改变，到2022年底，初始原型被添加到 Firefox 中。虽然第三方 cookie 弃用的路径取得了前进了一步又后退了一步，但 FedCM 工作一直在继续。不过，这不仅仅是规范在演变。浏览器中的代码已经推出。部分 FedCM 功能在2022年发布的 Chrome 和 Edge 108 中发布。在 2025 年，在Firefox中添加了一个完整版本的缺陷跟踪。

联邦凭证管理（FedCM）的初步支持在2023年被添加到 Selenium 中，并且是playwright的一个开放功能请求。该规范有一个关于浏览器自动化的顶级部分，因此人们理解这很重要。工作组在2024年 8 月发布了一个工作草案规范，但在发布候选版本之前还有很多工作要做。有一个编辑草案可供使用，并且定期更新。

让我们来看一下 FedCM 提供的特性。

联邦凭证管理功能

在我们研究 FedCM 功能之前，先了解一些有用的定义：

• RP 或依赖方：这是用户通过浏览器尝试访问的应用或数据的网站。这个应用触发了一个认证事件。

• IDP 或身份提供者：这是持有身份信息并与浏览器交互的持有者。在上面我称之为中央认证服务器。

• 用户代理：这只是浏览器的一个花哨术语。

这些是由 FedCM 规范使用的术语，因此我们将在本文的其余部分使用它们。让我们来看一下用户流程，包括基于重定向的和使用 FedCM 的用户流。

基于重定向流的用户流程图

这是用户第一次使用基于重定向的工作流程登录。

[按此放大上图]

当用户第二次登录时，它们被反弹到 IDP。但由于他们的 cookies 是有效的，所以他们看不到登录表单。

[按此放大上图]

使用 FedCM 的登录流程

用户第一次使用 FedCM 登录时的体验取决于依赖方请求的具体细节，但通常情况下，IDP 会用 iframe 提示登录凭据。

该图显示了“被动”模式的流程，它需要最少的用户交互。

[按此放大上图]

在步骤 12 中，一旦用户代理接收到令牌，FedCM 部分就完成了。RP 可能还有更多事情要做。

当用户第二次使用 FedCM 登录时，奇迹就发生了。当用户以前使用过 FedCM 并且没有超过一个帐户时，他们不会被提示登录，而是在不离开 RP 的情况下自动重新认证：

[按此放大上图]

FedCM 规范的作者考虑了其他登录情况，包括：

• 在这台设备上有多个账户登录到认证提供者

• 无效的用户账户

• 当用户注销了依赖方但没有注销身份提供者

• 如果用户最近注销了身份提供者

下面是用户看到的一个例子：

浏览器支持

根据 Cloudflare 提供的按市场份额划分的浏览器列表，这里列出了市场份额超过 1%的浏览器以及它们对 FedCM 的支持程度。

• Chrome：从版本 136 开始完全支持。Chrome 团队在 FedCM 工作组中非常活跃。

• Safari：支持这项工作，但截至撰写本文时尚未发布实现。 WebKit标准页面上页没有提及。

• Edge：从版本 136 开始完全支持。

• Firefox：正在努力支持，但截至本文发布时尚不支持。这是发布此功能的缺陷跟踪。Firefox 团队在 FedCM 工作组中很活跃，但从 2025 年 8 月起暂停实施。

• Samsung Internet：从版本 26 开始几乎完全支持。

• Opera：从版本 108 开始几乎完全支持，其中一个特性还在预览中。

• Brave：在2023年提到了对这项工作的支持，一个开放的GitHub问题提到了它，但最近没有动静。

IDP 支持

对身份提供者的支持正在增长，但肯定不是普遍的。根据2024年秋季的一份报告，以下身份提供者支持 FedCM：

• Google（这是他们的.well-known文件）

• NetID（GMX/Web.de）

• Shopify

• Seznam（一个捷克网络门户和搜索引擎）

• Mobage（一个游戏门户和社交网络）

• Times Internet（一家印度跨国技术公司）

• AMedia（一家报纸公司）

• Ory（一个支持 FedCM 的基础设施提供者）

人们对 FedCM 工作组也有更广泛的兴趣，工作组参与者名单中包括许多 IDP。

RP 支持

支持 FedCM 的 Web 应用程序更难追踪，但包括：

• Pinterest

• Kayak

• Booking.com

• Realtor.com

如果你想知道一个 RP 是否支持 FedCM，打开浏览器检查器中的登录页面并搜索嵌入在 JavaScript 中的字符串“ IdentityCredential ”。

支持的用例

FedCM 专注于以下用例：

• 用户登录，以一种注重隐私和安全的方式验证依赖方的用户在身份提供者处拥有账户。

• 将用户账户从浏览器管理的列表中断开连接。

还有其他与认证相关的用例，它们不是 FedCM 的重点，但与之相邻：

• 注册/注册流程由一个扩展处理，允许用户使用 FedCM 注册账户。帐户创建是在 IDP 和浏览器之间严格处理的。

• 注销用例也被覆盖了。当请求登录账户时，如果 IDP 没有提供账户，用户将被注销。IDP 也可以调用 API 将用户标记为已注销。

账户恢复和凭证管理不是由 FedCM 或其扩展处理的。

实现细节

FedCM 规范尚未最终确定。虽然本实现指南在发布时是正确的，但可能存在不准确之处。查看规范并与支持的浏览器进行测试是确保你的实现能工作的最佳方式。

浏览器、IDP 和 RP 都有实现责任。本文不打算介绍浏览器实现；如果你您正在构建浏览器，请查看规范。

网站实现细节

登录

网站/RP 通过使用身份提供者 API 开始认证过程。测试 API 支持并启动流程（添加按钮处理程序，如下所示，或在页面加载后触发登录）：

$('#sign-in').addEventListener('click', async e => {  try {    if ('IdentityCredential' in window) {      await signIn();    } else {      throw new Error('FedCM not supported.');    }  } catch (error) {    //  跳转到IDP  }});

你应该测试 FedCM 支持，因为浏览器支持是不完整的，用户可以禁用它。如果需要，可以回退到其他方法。

让我们看看 signIn 函数：

const signIn = async () => {      const credential = await navigator.credentials.get({        identity: {          // 指定此依赖方支持的IdP或idps          providers: [{              configURL: 'https://accounts.idp-1.example/config.json',              mode: 'active',              params: {                scope: 'drive'              },              mediation: 'optional',              clientId: 'CLIENT_ID1'            },            {              configURL: 'https://accounts.idp-2.example/config.json',              mode: 'active',              params: {                scope: 'drive'              },              mediation: 'optional',              clientId: 'CLIENT_ID2'            }          ]        }      }, );      const {        token      } = credential;

该请求传递客户端标识符和配置 URL，这有助于 IDP 识别用户。让我们看看其他参数。 mode 可以是“主动”或“被动”。“主动”请求需要用户交互，而被动请求则不需要，具体取决于调解值。调解有四个已定义的值，决定了登录过程可以在多大程度上无需用户交互进行。 params 包含传递给登录进程的额外参数。例如，使用 loginHint 指定要显示的帐户，或使用 nonce 来防止重放攻击。

然后浏览器将向用户显示所有请求和正确响应的 IDP。RP 可以通过查看 credential.configURL 来检查用户登录到了哪一个，它告诉 RP 浏览器成功连接到哪个 IDP。有效的令牌是成功认证的结果。在接收到令牌后，RP 必须使用它。该逻辑取决于应用程序。一旦获得令牌，FedCM 流程就完成了。

断开连接

一旦使用了 IDP，就会在浏览器中存储其记录。如果这是一个公共浏览器或账户是敏感的，用户可能想要断开连接。这是通过使用以下 JavaScript 完成的：

async function handleIdentityCredentialDisconnect() {  // 检查IdentityCredential API是否存在  if (!window.IdentityCredential) {    console.error('IdentityCredential API is not available in this browser');    return;  }
  try {    // 调用disconnect并等待promise    const result = await IdentityCredential.disconnect({      configURL: 'https://idp.com/config.json',      clientId: 'rp123',      accountHint: 'account456'    });
    console.log('IdentityCredential disconnect successful:', result);    return result;  } catch (error) {    console.error('IdentityCredential disconnect failed:', error);    throw error; // 如果你希望调用代码处理它，则重新抛出  }}
// 使用示例:handleIdentityCredentialDisconnect()  .then(result => {    console.log('Disconnect operation completed successfully');  })  .catch(error => {    console.error('Disconnect operation failed:', error);  });

断开连接可能由于各种原因而失败，例如用户在浏览器中禁用了 FedCM。接下来让我们看看 IDP 的实现。

IDP 实现细节

IDP 需要实现规范的 HTTP API 部分。你可以查看2024年 8 月的草案和最新的编辑草案。由于所提议的标准正在迅速发展，因此在实现 FedCM 时，最好的选择是使用你想要支持的浏览器进行测试，并参考编辑的草案和谷歌FedCM文档。

实现细节

认证提供者需要提供几个文件。让我们假设认证提供者托管在“auth.example.com”。以下是 FedCM 工作所需的文件：

• "https://example.com/.well-known/web-identity"

• "https://auth.example.com/config.json"

• "https://auth.example.com/accounts"

• "https://auth.example.com/client_metadata"

• "https://auth.example.com/id_assert"

• "https://auth.example.com/login"

• "https://auth.example.com/logout"

让我们逐一研究一下。

.well-known 文件

首先是 .well-known 文件，它有一个明确的位置，但如果 RP（依赖方）和 IDP（身份提供方）是同一个站点，则它不是必须的。它必须位于 IDP 域名的根目录下这个路径。如果你的 IDP 存在于" idp.example.com "，那么这个文件必须存在于" example.com/.well-known/web-identity "。

这个文件位于根域名是为了保护 RP 的身份：

“在 IDP 域名根目录存在一个文件是强制执行的，以确保文件名不会引入关于正在访问的 RP 的指纹。” —— https://w3c-fedid.github.io/FedCM/#manifest-fingerprinting

关于这个文件内容的一个示例：

{  "provider_urls": [    "https://auth.example.com/config.json"  ],  "accounts_endpoint": "https://auth.example.com/accounts",  "login_url": "https://auth.example.com/login"}

如果存在 accounts_endpoint 和 login_url ，它们必须与下面提到的配置文件中的值匹配。如果配置文件中存在客户端元数据端点，则这些字段是必需的。

配置文件

在请求了 .well-known 文件之后，浏览器会请求适当的配置文件。RP 可以请求与 provider_urls 数组中不同的配置文件，只要 accounts_endpoint 和 login_url 与 well-known 文件中的相同即可。这允许为 staging 和 prod 环境使用不同的配置文件。

配置文件样例内容如下：

{  "accounts_endpoint": "/accounts",  "client_metadata_endpoint": "/client_metadata",  "id_assertion_endpoint": "/id_assert",  "login_url": "/login",  "disconnect_endpoint": "/logout",  "branding": {    "background_color": "green",    "color": "0xFFEEAA",    "icons": [      {        "url": "https://idp.example/icon.ico",        "size": 25      }    ],    "name": "Example"  }}

让我们更详细地看看这些字段。

accounts_endpoint

accounts_endpoint 处的代码负责返回用户在 IDP 上登录的账户列表。它将接收带有 SameSite=None 的 cookies、一个 Sec-Fetch-Dest 头部，以及其他任何内容的 cookie（没有指示哪个 RP/网站正在请求用户登录）。IDP 应在验证 Sec-Fetch-Dest 头部和 cookies 后返回。它应该返回如下所示的 JSON：

{  "accounts": [    {      "id": "1234",      "given_name": "John",      "name": "John Doe",      "email": "john_doe@idp.example",      "picture": "https://idp.example/profile/123",      "approved_clients": [        "123",        "456",        "789"      ],      "login_hints": [        "john_doe"      ],      "domain_hints": [        "idp.example"      ]    },    {      "id": "5678",      "given_name": "Johnny",      "email": "johnny@idp.example",      "picture": "https://idp.example/profile/456",      "approved_clients": [        "abc",        "def",        "ghi"      ],      "login_hints": [        "email=johhny@idp.example",        "id=5678"      ],      "domain_hints": [        "idp2.example"      ],      "label_hints": [        "l1"      ]    }  ]}

对于返回的帐户，有各种过滤选项可用。 login_hint 和 domain_hint 允许 RP 只请求匹配某些值的帐户。如果一个 RP 只想要“idp.example”域，则只返回 id 为“ 1234 ”的帐户。 label_hints 匹配配置中的值，也限制帐户。不同之处在于 label_hints 不需要 RP 的配置，而是使用 RP 请求的配置文件中的 account_label 进行配置。

规范中定义的其他字段。

client_metadata_endpoint

该端点接收客户端标识符，并返回服务条款、隐私策略和其他元数据。支持此端点是可选的，但对创建新帐户很有帮助。

id_assertion_endpoint

该端点接受与 RP 对应的 client_id 和与终端用户对应的帐户 id，以及其他一些参数，包括用户是否自动登录。请求包括 RP 源、cookies 和 Sec-Fetch-Dest 报头。

该端点返回一个令牌，以及 continue_on 字段中的 URL（可选）。下面是一个例子：

 {    "token": "..."  }

如果提供了 continue_on 字段，它包含“用户代理将在弹出窗口中打开该 URL 以完成认证过程”。当 IDP 需要在认证完成之前执行其他步骤时，请使用此字段。

login_url

如果用户未登录，浏览器会显示这个 IDP URL。此页面不知道引起登录请求的 RP 的任何信息，以保护隐私。此 URL 也能处理其他认证用例，例如 MFA 挑战或帐户恢复。但是，FedCM 根本没有定义这些流。当 IDP 对用户进行了满意的认证后，它可以发送 Set-Login: logged-in 标头或调用 navigator.login。在 HTML 页面上 setStatus("logged-in")，然后调用 IdentityProvider.close()关闭窗口。

disconnect_endpoint

这是用户代理发出断开连接请求的 URL，因此 IDP 不再存储在浏览器中。它获取表示 RP 的 client_id 和包含要断开连接的帐户 id 的 account_hint。它还获取 IDP cookies 和 Sec-Fetch-Dest 报头。它应该使用已断开连接的帐户 id 进行响应。这可能与 account_hint 中的帐户 id 不同。

branding

品牌字段允许 IDP 控制 FedCM 登录用户体验的外观，包括名称、颜色和图标。它是最小化的，由浏览器实现控制。

安全措施

如上所述，使用 FedCM 的主要原因是，对于现代网络认证至关重要的 cookies 和重定向原语可以用来跟踪用户。FedCM 通过几种方式避免了这一点。它限制了浏览器调用的每个端点可用的信息，只提供所需的信息。下面的表格显示了从规范中每个端点发送的内容。

为了防止合法的浏览器请求被滥用，必须在每个非弹出式 FedCM 浏览器请求中检查 Sec-Fetch-Dest 报头。此检查必须由 IDP 完成，值应该始终为 webidentity。Cookies 发送时带有 Samesite=None，这可能看起来令人担忧。但是这些请求是由浏览器严格控制的，并且该设置允许跨域认证，其中 RP 和 IDP 位于不同的域。还有一整节是关于规范作者考虑并记录的安全措施的。

什么东西在不断变化

有很多。

虽然它已经在 Chrome 和 Edge 上推出了，但从浏览器端和 IDP 端来看，还有很多工作要做。有两项努力正在发生变化：

• IDP注册，旨在使其更容易地增加 IDP 支持 FedCM 的数量。

• 委托，这提高了联合登录的隐私方面，特别是确保 IDP 无法知道哪个 RP 委托了认证给它。

我预计 FedCM 将获得越来越多的动力，但在成为发布的 w3c 标准之前，还需要完成很多个月甚至几年的工作。你可以通过加入W3C工作组或W3C社区组来参与。有定期的视频会议，你也可以查看正在进行的规范。你可以从这个会议演讲中了解更多关于浏览器 UX 变化的信息。最后，你可以在FedCM GitHub仓库中提交问题并关注 PRs。

对利益相关方的影响

让我们看看对主要利益相关方的影响。

开发者

使用 FedCM 是一个简单的实现任务：调用原生浏览器 API。当使用时，FedCM 允许用户在不离开网络应用的情况下在 IDP 上进行认证，使用一种原生的、安全的、注重隐私的方法。一些值得关注的问题：

覆盖范围

FedCM 是一个不断发展的提议标准，目前在许多浏览器（包括 Safari 和 Firefox）上都不可用。虽然 Chrome 拥有大部分桌面浏览器市场份额，但这可能不足以证明添加此功能的合理性。缺乏 Safari 的支持意味着 FedCM 在桌面上不会是一个完整的解决方案，更不用说移动设备了。计划维护一个后备登录方法。

替代方法

FedCM 要成为唯一的登录方法还有很长的路要走。就像魔术链接或密码一样，网站必须提供其他方式让用户登录，这既是因为浏览器的支持，也是因为用户的偏好。

品牌化

认证和注册是应用程序的前门。通过使用 FedCM，你减少了摩擦，但放弃了 UX 控制。这不仅包括外观和感觉，还包括提供其他认证方法，如 SAML 或 OIDC。

身份提供商

作为身份提供商实施 FedCM 并不像网站开发者那样简单，但回报也更高。虽然端点定义得相当清楚，但必须遵循安全规则，如 cookie 和头部检查。到目前为止，FedCM 工作主要由浏览器供应商推动，因此 IDP 实施指南没有得到应有的关注。然而，支持 FedCM 可以为身份提供商提供与支持其他安全、注重隐私的认证方法相同的好处。通过支持这一提议的标准，IDP：

• 让用户在没有任何重定向的情况下登录

• 增加最终用户的登录选项

• 如果浏览器最终淘汰第三方 cookies，做好准备

• 可以帮助 RP 满足 GDPR、CCPA 和其他数据保护要求等隐私法规

最终用户

要使用 FedCM，最终用户必须改变他们的登录行为，但由于分阶段推出，应该能够以他们认为合适的方式管理这一点。将会有很长一段时间的退路，所以如果最终用户对浏览器弹出窗口感到困惑，他们可以退回到更正常的登录体验。目前尚不清楚非浏览器工具（如密码管理器）将如何与 FedCM 互动，尽管对用户代理自动化的显著支持意味着这些工具可能能够这样做。

结论

FedCM 至关重要。这个提议的标准已经在大多数桌面流量上得到了支持，并且正在积极开发中，工作组中有三十个组织参与。然而，大多数人会从等待另一个草案发布和 API 固化中受益。如果你喜欢生活在边缘，并且谷歌是需要支持的身份提供者，你现在就可以使用 FedCM。最后，参与塑造这个提议的标准。如上所述，有会议和其他机会可以贡献。

感谢 Sam Goto 和 Bruno Couriol 对本文的审阅。

原文链接：

https://www.infoq.com/articles/federated-credentials-management-w3c-proposal/