作家 | Dan Moore 凯发·k8国际娱乐网

译者 | 刘雅梦

谋划 | 丁晓昀

联邦凭证管制（federalcredential Management，FedCM）API 是一个冷漠中的 Web 规范，可能会影响真实统共通过浏览器登录应用秩序的东说念主。FedCM 在 W3C 里面开发，旨在通过引入浏览器原生的花式来处理连合登录，从而创建一个愈加保护心事的 Web。当一个应用秩序将登录过程寄托给另一个称为身份提供者的应用秩序时，就会发生连合登录。

FedCM 起初的动机是为连合登录提供更好的基础，并得到浏览器的营救。与一般用途的 Web 原语（如重定向、iframe 和第三方 cookie）不同，部分原因是这些原语也被告白商用来在收罗上追踪用户，开发者不错使用原生 API。天然 谷歌 Chrome 将破碎第三方 cookies 的决定权交给了用户，但其他浏览器 仍然默许破碎统共或大普遍第三方 cookies。

FedCM 专注于用户心事，并运用浏览器的原生 UI 元素，旨在构建一个愈加一致和安全的登录体验，并责罚莫得浏览器功能就无法责罚的问题。这些问题包括可用的身份提供者太多（NASCAR 标志问题）和发现身份提供秩序。

伸开剩余96%

若是你使用第三方酬酢提供商登录 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 的刷新或 Java 苦求等认证功能可能会失败。然则，第三方 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 或身份提供者：这是握有身份信息并与浏览器交互的握有者。在上头我称之为中央认证服务器。

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

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 问题提到了它，但最近莫得动静。

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 的基础设施提供者）

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

Pinterest

Kayak

Booking.com

Realtor.com

若是你念念知说念一个 RP 是否营救 FedCM，怒放浏览器查抄器中的登录页面并搜索镶嵌在 Java 中的字符串“ IdentityCredential”。

营救的用例

FedCM 专注于以下用例：

用户登录，以一种详确心事和安全的花式考据依赖方的用户在身份提供者处领有账户。

将用户账户从浏览器管制的列表中断开勾搭。

用户登录，以一种详确心事和安全的花式考据依赖方的用户在身份提供者处领有账户。

将用户账户从浏览器管制的列表中断开勾搭。

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

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

刊出用例也被逃匿了。当苦求登录账户时，若是 IDP 莫得提供账户，用户将被刊出。IDP 也不错调用 API 将用户象征为已刊出。

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

刊出用例也被逃匿了。当苦求登录账户时，若是 IDP 莫得提供账户，用户将被刊出。IDP 也不错调用 API 将用户象征为已刊出。

账户归奖饰凭证管制不是由 FedCM 或其扩张处理的。

竣事细节

FedCM 规范尚未最终细则。天然本竣事指南在发布时是正确的，但可能存在不准确之处。检察规范并与营救的浏览器进行测试是确保你的竣事能就业的最好花式。

浏览器、IDP 和 RP 齐有竣事就业。本文不缱绻先容浏览器竣事；若是你您正在构建浏览器，请 检察规范。

网站竣事细节

登录

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

你应该测试 FedCM 营救，因为浏览器营救是不完好的，用户不错禁用它。若是需要，不错回退到其他方法。

让咱们望望 signIn函数：

然后浏览器将向用户表现统共请乞降正确反应的 IDP。RP 不错通过检察 credential.configURL来查抄用户登录到了哪一个，它告诉 RP 浏览器见效勾搭到哪个 IDP。灵验的令牌是见效认证的恶果。在接纳到令牌后，RP 必须使用它。该逻辑取决于应用秩序。一朝取得令牌，FedCM 过程就完成了。

断开勾搭

一朝使用了 IDP，就会在浏览器中存储其记载。若是这是一个巨匠浏览器或账户是敏锐的，用户可能念念要断开勾搭。这是通过使用以下 Java 完成的：

断开勾搭可能由于多样原因而失败，举例用户在浏览器中禁用了 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"

"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/-fingerprinting

对于这个文献实践的一个示例：

若是存在 accounts_endpoint和 login_url，它们必须与底下提到的竖立文献中的值匹配。若是竖立文献中存在客户端元数据端点，则这些字段是必需的。

竖立文献

在苦求了 .well-known文献之后，浏览器会苦求相宜的竖立文献。RP 不错苦求与 provider_urls数组中不同的竖立文献，惟有 accounts_endpoint和 login_url与 well-known 文献中的相通即可。这允许为 staging 和 prod 环境使用不同的竖立文献。

竖立文献样例实践如下：

让咱们更详确地望望这些字段。

accounts_endpoint

accounts_endpoint处的代码施展复返用户在 IDP 上登录的账户列表。它将接纳带有 SameSite=None的 cookies、一个 Sec-Fetch-Dest头部，以过火他任何实践的 cookie（莫得指导哪个 RP/ 网站正在苦求用户登录）。IDP 应在考据 Sec-Fetch-Dest头部和 cookies 后复返。它应该复返如下所示的 JSON：

对于复返的帐户，有多样过滤选项可用。 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（可选）。底下是一个例子：

若是提供了 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 寄托了认证给它。

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 和其他数据保护要求等心事法例

让用户在莫得任何重定向的情况下登录

加多最终用户的登录选项

若是浏览器最终淘汰第三方 cookies，作念好准备

不错匡助 RP 称心 GDPR、CCPA 和其他数据保护要求等心事法例

最终用户

要使用 FedCM，最终用户必须改变他们的登录行为，但由于分阶段推出，应该省略以他们以为合适的花式管制这少许。将会有很长一段时刻的退路，是以若是最终用户对浏览器弹出窗口感到困惑，他们不错反璧到更广宽的登录体验。咫尺尚不了了非浏览器器具（如密码管制器）将何如与 FedCM 互动，尽管对用户代理自动化的权臣营救意味着这些器具可能省略这么作念。

结 论

FedCM 至关进击。这个冷漠的规范仍是在大普遍桌面流量上得到了营救，况兼正在积极开发中，就业组中有三十个组织参与。关联词，大普遍东说念主会从恭候另一个草案发布和 API 固化中受益。若是你心爱生涯在角落，况兼谷歌是需要营救的身份提供者，你咫尺就不错使用 FedCM。终末，参与塑造这个冷漠的规范。如上所述，有会议和其他契机不错孝顺。

感谢 Sam Goto 和 Bruno Couriol 对本文的审阅凯发·k8国际娱乐网。

发布于：北京市