发布时间：2025 年 9 月 8 日
多个行业的领导者都深知，在提供出色用户体验的同时保护隐私至关重要。Seznam 致力于提供出色的用户体验和隐私保护，并成功集成了 Federated Credential Management (FedCM)。
可从 FedCM 中受益的公司
各个领域的组织都在将 FedCM 与其解决方案相集成。由于 FedCM 专为联合身份管理而设计，因此身份提供方 (IdP) 是其主要受益者。他们使用此功能来提供更出色的登录体验。电子商务服务提供商和支付服务提供商（其中许多也充当身份提供商）也发现了通过 FedCM 改善用户体验的机会。
Seznam
Seznam 是一家欧洲技术公司和身份提供方，覆盖了 90% 的捷克人口。它是一个集社交、知识和内容于一体的中心。Seznam 采用了 FedCM，以便在合作伙伴平台上运营的网店的客户可以使用自己的 Seznam 账号登录。
借助 FedCM，Seznam 在合作伙伴网络上实现了用户登录率的大幅提升，改善了用户体验，并实现了无论第三方 Cookie 是否可用，身份流程都保持一致。
设计初衷
Seznam 之所以选择实现 FedCM，是因为它具有以下几项公认的优势：
- FedCM 的设计以最终用户为中心，让用户能够控制向 IdP 提供的信息。这与 Seznam 为用户打造安全私密环境的愿景相符。
- FedCM 是一项内置的浏览器功能，与 Seznam 使用 OAuth 2.0 标准的现有登录体验兼容。
- FedCM 是一种注重隐私保护的身份联合方法。例如，如果用户登录，则用户对信赖方 (RP) 的访问仅与 IdP 共享。这与 Seznam 对可持续业务的看法一致。
实现细节
Seznam 在其现有的 OAuth 解决方案之上实现了一个 FedCM 层。在此架构中，FedCM 流程可将 OAuth 授权代码从 IdP 安全地传输到 RP。
实现工作量
Seznam 发现 FedCM 实现简单明了，并且与他们现有的方法一致。其研究和 API 实现历时一个月，需要两名开发者。我们用了不到两个月的时间就将 FedCM 投入了生产。该过程是迭代的，我们花费了大量时间来研究 API。
挑战
作为早期采用者，Seznam 发现了一些挑战，并提供了有助于完善 API 的宝贵反馈。
支持多个身份提供方
Seznam 对 FedCM 支持多个身份提供方很感兴趣。此功能旨在让用户在合作伙伴 RP 上选择 Seznam 账号或 Google 账号。不过，当 Seznam 首次着手实现 FedCM 时，该功能还处于早期实现阶段，开发者必须注册源试用并使用令牌才能为用户启用该功能。因此，Seznam 选择等待该功能在 Chrome 稳定版中发布。
此功能从 Chrome 136 开始提供，开发者可以配置对多个身份提供方的支持。例如，为了同时支持 Seznam 和 Google 身份提供商，IdP 可以在单个 get() 调用中包含这两个提供商，RP 也可以单独执行此操作：
// Executed on the RP's side:
const credential = await navigator.credentials.get({
identity: {
providers: [
{
// IdP1: Seznam config file URL
configURL: 'https://szn.cz/.well-known/web-identity',
clientId: '123',
},
{
// Allow Google Sign-in
configURL: 'https://accounts.google.com/gsi/fedcm.json',
clientId: '456',
},
],
},
});
Seznam 表示此功能将成为其解决方案的一部分。此外，FedCM 团队正在实现对多个 SDK 的支持，并支持多次调用 get()。
专用 DNS
在测试阶段，Seznam 遇到了与其网络配置相关的问题。其测试 IdP 服务器位于专用网络中，只能通过专用 DNS 访问。在公开展示之前，这种设置通常用于内部测试和开发环境。
不过，这种设置会带来一个难题：由于 well-known 文件必须从 eTLD+1 提供，而私有开发网域未在公共后缀列表中注册，因此浏览器不会发送请求来提取托管在开发网域中的 well-known 文件：
login.idp.example：生产网域示例。idp.example/.well-known/web-identity：生产环境中的well-known文件示例。login.dev.idp.example：示例开发网域。login.dev.idp.example/.well-known/web-identity：开发环境中的well-known文件示例。
当 FedCM 实现托管在私有网域上时，浏览器对 well-known 文件的请求会导致以下错误：
The fetch of the well-known file resulted in a network error: ERR_NAME_NOT_RESOLVED
您可以通过启用 Chrome #fedcm-without-well-known-enforcement 标志来解决此错误。启用此标志后，浏览器会跳过提取 well-known 文件以进行测试。了解如何在 Chrome 中启用测试 flag。
自定义信息披露
Seznam 还希望在初始 FedCM 界面设计中添加其他信息。标准 FedCM 对话框会向用户显示一条固定消息，指出特定数据（通常是用户的个人资料照片、姓名和电子邮件地址）会与 RP 共享。
FedCM 团队采纳了反馈意见，并扩展了 API，以便自定义向用户显示的披露声明。例如，借助继续功能，IdP 可以将用户重定向到自定义页面，以请求更多信息或权限。自定义参数和字段功能（从 Chrome 132 开始支持）可实现进一步的自定义。
依赖方来源验证
IdP 服务器必须验证传入的 FedCM 请求中的 Origin HTTP 标头，以确保该请求与 RP 预先向 IdP 注册的来源相符。这样可确保 FedCM ID 断言请求来自已获授权的 RP，而不是来自使用 client_id 的攻击者。
Seznam 存在一种特殊情况：当其合作伙伴 RP 向 Seznam 注册时，它不会请求 RP 的来源数据。这意味着无法验证 RP 的来源。
Seznam 的 FedCM 集成基于现有的 OAuth 解决方案构建。它采取了替代方案，即验证 RP 的 client_id 和 client_secret，以确保解决方案在不检查来源的情况下仍保持安全。
面向用户的身份提供方网域
Seznam 的用户身份验证基础架构主要在 szn.cz 网域上运行，其中托管了 FedCM 所需的 IdP 端点。不过，其主要公司身份以及用户广泛认可和信任其服务的网域是 seznam.cz。
FedCM 对话框会显示 IdP 端点的实际源站网域：szn.cz。熟悉 seznam.cz 品牌的用户在登录过程中看到系统提示使用不太熟悉的 szn.cz 网域登录时，可能会感到困惑并犹豫不决。
从 Chrome 141 开始，FedCM 不允许显示与托管 IdP 实现的网域不同的网域。此限制是一项有意做出的设计选择，旨在确保用户透明度。不过，FedCM 团队认识到此限制可能会带来的挑战，目前正在讨论可能的调整。
影响
借助 FedCM API，Seznam 现在可以为合作伙伴用户提供单点触控授权流程。它重点介绍了 FedCM 的用户体验与其他身份验证方法相比的优势。
虽然 Seznam 注意到，改用 FedCM 登录的网站上的用户互动度显著提升，但它并未进行全面分析，以隔离其他因素的精确直接影响。在集成 FedCM 之前，该实现允许使用已征得用户同意的哈希电子邮件进行用户身份识别，从而实现访客结账。进行此类分析的难点在于，需要估计用户转化是否可归因于 FedCM，或者用户是否会使用访客结账完成购买交易。Seznam 的假设表明，FedCM 改进的易用性可能促成了这一更高的转化率。
总结
Seznam 成功实现了 FedCM，在现有 OAuth 解决方案的基础上提供了一种替代授权流程。虽然 Seznam 在身份提供方支持、专用 DNS 设置、披露声明文本自定义、信赖方来源验证和面向用户的网域显示方面遇到了一些挑战，但自实现以来，该 API 已日趋成熟。FedCM 团队已采纳 Seznam 和其他早期采用者的反馈，从而打造出更出色的工具来应对这些挑战。接下来，Seznam 计划实现 FedCM 对多个身份提供方的支持