摘要：对于普通用户来说，登录就是输入账号密码，或者点一个使用谷歌账户登录的按钮。但在这背后，原有的认证机制依赖的是一套复杂的体系：重定向、第三方cookie、iframe嵌套。

谷歌在其开发者博客中发布了一则更新：从Chrome 136版本起，谷歌身份服务默认启用了FedCM。

这条看似普通的技术新闻，在开发者社区引起了广泛关注。原因很简单这项标准，有可能彻底改变我们在网络上登录的方式。

对于普通用户来说，登录就是输入账号密码，或者点一个使用谷歌账户登录的按钮。但在这背后，原有的认证机制依赖的是一套复杂的体系：重定向、第三方cookie、iframe嵌套。

这些机制运行了20多年，支撑了整个Web的身份验证体系。但也正是这些机制，让用户隐私在多个跳转中被反复暴露，成为广告商追踪用户行为的主要工具之一。

于是FedCM出现了。它是由W3C发起，谷歌、Mozilla等浏览器厂商参与制定，目标是用浏览器原生能力替代原有机制，在提升用户隐私保护的同时，让登录变得更安全、更统一。

但这项技术是否真有如此大的能量？它是否会成为又一个由大厂推动的事实标准？又是否会带来开发、兼容性、隐私等方面的争议？

2002年，SAML 1.0 发布，这是第一个标准化的联合登录协议随后发展出SAML 2.0、OAuth 2.0 以及 OIDC。

它们的共同特点是：通过重定向浏览器到身份提供者，由IDP完成认证后，再重定向回原网站。谷歌、Facebook、微软等平台，都是通过类似机制提供第三方登录服务。

但这种流程有一个关键依赖：那就是第三方cookie。第三方cookie允许IDP在多个网站间识别同一个用户，这虽然方便了认证，但也成了广告公司跨站追踪用户的工具。

FedCM正是针对这个问题提出的解决方案。它不依赖cookie和重定向，而是通过浏览器控制的API，来统一管理身份验证流程，在技术上切断了IDP获取用户在不同网站行为的可能性。

传统的认证流程中，开发者可以自定义登录界面，添加自家品牌元素，甚至嵌入多重认证、安全提示等。

而FedCM将认证流程交由浏览器控制，是否意味着开发者失去了前门的话语权？

从技术文档来看，FedCM确实限制了RP对登录流程的控制。认证界面由浏览器统一弹出，IDP只能通过branding字段控制颜色、图标和名称，RP无权自定义界面内容。

这在提升安全性和一致性的同时，也意味着开发者无法引导用户进行某些操作，比如推荐使用某种身份认证方式。

但从用户角度看这种限制反而提升了体验。FedCM支持被动登录模式，即用户访问网站时，如果之前已经登录过且只有一个账户，浏览器将自动完成认证，不需要跳转或再次输入信息。对于移动端用户，这种无跳转的快捷登录是很方便的。

浏览器在认证流程中扮演了用户代理的角色，而不是开发者代理。这种设计也许看起来让开发者失去控制，但实际上是将控制权交还给用户。

隐私保护是FedCM提出的核心价值之一。但质疑也随之而来：浏览器依旧发送cookie，只是加了SameSite=None，这难道不还是在跨站传输信息？

FedCM对隐私的保护，并不是简单地关掉cookie，而是从请求发起的上下文入手。所有FedCM请求都必须带有 Sec-Fetch-Dest: webidentity 头部，只有浏览器控制的认证流程才能触发这个请求。

IDP不能通过普通JavaScript或iframe模拟这一请求，从而无法在后台跟踪用户行为。

此外浏览器不会向IDP透露是哪一个RP发起的认证请求，防止IDP收集用户在不同网站的登录记录。

当然这不代表FedCM是完美的隐私方案。它仍然需要IDP谨慎处理用户数据，避免在响应中嵌入意图识别RP的内容。标准中对此有明确要求但执行效果仍有待观察。

FedCM不是一个新产品，它也不直接面向普通用户。但它可能是Web身份认证过去20年来最重要的一次架构调整。

从重定向到浏览器API，从cookie到用户代理控制，FedCM的每一个设计，都在回应一个问题：如何在不暴露用户行为的前提下，实现跨站认证。

目前已有谷歌、Shopify、Seznam等多个IDP实现了FedCM接口，Pinterest、Kayak、Booking.com等站点也开始支持。

虽然Safari和Firefox的支持仍在推进，但主流流量已经初步落地。也许对大多数用户来说，登录时少了几次跳转、多了一个弹窗，并不值得注意。但在这背后，是整个Web对隐私、安全、效率的再平衡。

“真正的隐私保护，不是断开一切连接，而是在连接中保护彼此。”FedCM的出现，正在试图回答这个问题。

来源：瑛子的分享日常