米乐·M6(中国大陆)官方网站-米乐门户入口

　　联邦凭证管理（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 应用程序开始添加身份验证。这种方法将用户数据隔离开来，要求他们在应用程序之间重新输入凭据，并给每个应用程序增加了安全负担。

　　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 月发布了一个工作草案规范，但在发布候选版本之前还有很多工作要做。有一个编辑草案可供使用，并且定期更新。

　　M6网页版 米乐M6官网登录入口

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　“在 IDP 域名根目录存在一个文件是强制执行的，以确保文件名不会引入关于正在访问的 RP 的指纹。” ——

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

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

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

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

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

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

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

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

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

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

　　委托，这提高了联合登录的隐私方面，特别是确保 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：

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

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