开云kaiyun 将用户账户从浏览器料理的列表中断开联结-kai云体育app官网版下载官网
作家 | Dan Moore 开云kaiyun
译者 | 刘雅梦
策划 | 丁晓昀
联邦凭证料理（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 应用程序更难追踪，但包括：
Kayak
Booking.com
Realtor.com
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 对本文的审阅开云kaiyun。
发布于：北京市