多个行业的领导者都深知，在为所有用户提供出色体验的同时保护隐私至关重要。Seznam 致力于提供出色的用户体验和隐私保护，已成功集成 Federated Credential Management (FedCM)。
目标客户群：可从 FedCM 中受益的公司
各个领域的组织都已将 FedCM 与其解决方案集成。鉴于 FedCM 专为联合身份管理而设计，身份提供方 (IdP) 是其主要受益者，他们可以使用 FedCM 来提供更出色的登录体验。电子商务服务提供商和支付服务提供商（其中许多也充当身份提供商）也发现了通过实现 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's config file URL
configURL: 'https://szn.cz/.well-known/web-identity',
clientId: '123',
},
{
// Also 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：生产环境中的知名文件示例。login.dev.idp.example：示例开发网域。login.dev.idp.example/.well-known/web-identity：开发环境中的知名文件示例。
当 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 中启用测试标志。
自定义信息披露
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 以来，该 API 已日趋成熟。FedCM 团队已采纳 Seznam 和其他早期采用者的反馈，从而能够提供更好的工具来解决这些挑战。下一步，Seznam 计划实现 FedCM 对多个身份提供方的支持。