查看第三方 Cookie 变更对登录工作流程的影响

Chrome 提议借助第三方 Cookie 为用户提供全新选择体验。如果用户选择在不使用第三方 Cookie 的情况下浏览,您的网站需要做好准备。

在此页面上,您可以了解到 并提及可能的解决方案

如果您的网站仅处理同一网域和子网域内的流,例如 publisher.examplelogin.publisher.example,便不会使用跨网站 Cookie 和您的登录流程预计不会受第三方 Cookie 变更的影响。

不过,如果您的网站使用单独的域进行登录,例如 Google 登录Facebook 登录,或者您的网站需要共享用户 您有机会在多个网域或子网域间进行身份验证 您需要对自己的网站进行更改 以确保顺利过渡到 跨网站 Cookie。

测试您的登录流程是否受第三方 Cookie 影响的最佳方法 也就是完成注册、密码恢复、登录和 启用了第三方 Cookie 测试标记的退出流程。

这是在限制第三方 Cookie 后需要检查的事项 Cookie:

  • 用户注册:可以按预期创建新账号。如果使用的是 第三方身份提供方,请检查新账号注册是否有效
  • 密码恢复:密码恢复功能可按预期在网页界面中恢复, 以及接收密码恢复电子邮件。
  • 登录:登录工作流在同一个网域中,并且在以下情况下运行 导航到其他网域请务必测试每一次登录集成。
  • 退出账号:退出流程按预期运行,用户仍会保留 退出了账号。

您还应测试需要用户登录的其他网站功能是否仍然存在 无需跨网站 Cookie 即可正常运行,尤其是在加载网页时 跨网站资源例如,如果您使用 CDN 加载用户个人资料图片 确保其仍可正常运行如果您有关键用户历程,例如 结账时,这类功能需要登录才能使用。

在接下来的部分中,您将更具体地了解这些流如何 可能受到影响

联合身份

登录按钮,如使用 Google 账号登录Facebook 登录和 如果使用 Twitter 登录,则明确说明您的网站使用的是 联合身份提供方。由于每个联合身份提供方都有 最佳做法是检查提供商的 文档,或与他们联系以获取进一步指导。

如果您使用的是已弃用 Google 登录 JavaScript 平台库,详细了解 迁移至新版 Google Identity Services 库进行身份验证 和授权。

使用新版 Google Identity 服务库的大多数网站都可以 因为该库会静默迁移FedCM 确保兼容性。我们建议您测试自己的网站 启用第三方 Cookie 测试标记后,如果需要, 使用 FedCM 迁移核对清单做好准备。

单独的登录网域

有些网站只会使用其他域名来验证用户的身份 有资格使用同网站 Cookie,例如网站使用 example.com 作为主 Cookie 以及登录流程的 login.example(可能需要访问 第三方 Cookie 来确保用户在 网域。

对于此情况,可能的迁移路径包括:

  • 关于使用第一方(“同网站”)Cookie 的更新:更改了 确保登录流程托管在同一网域(或 子网域)作为主网站,该网址将仅使用第一方 Cookie。这可能会 所需的工作量更大,具体取决于基础架构的设置方式。
  • 使用 Related Website Sets (RWS)Related Website Sets 启用 限制在一小部分相关网域之间跨网站 Cookie 访问。RWS 是 Privacy Sandbox API 专为支持这种应用场景而打造。不过,只有 RWS 支持在有限数量的网域间跨网站 Cookie 访问。
  • 如果您要对 5 个以上关联网域中的用户进行身份验证, 探索 FedCM联合凭据管理 (FedCM) 支持 身份提供方可以依靠 Chrome 处理与身份相关的流程, 要求使用第三方 Cookie在本例中,您的“登录网域”可以作为 FedCM 身份提供者,并用于验证您 网域。

多个网域

如果商家在不同网域或子网域上托管了多款产品, 它可能需要在这些产品之间共享用户会话,在这种情况下, 要求在多个网域之间访问第三方 Cookie。

在这种情况下,通常在同一网域下托管所有产品 不切实际。在这种情况下,可能的解决方法如下:

  • 使用 Related Website Sets:需要跨网站 Cookie 访问时 在一小部分相关网域之间分配流量。
  • 使用 Federation Credential Management (FedCM):当 网域较大,您就可以使用单独的登录网域 提供商,并使用 FedCM 对您的各个网站的用户进行身份验证。

登录解决方案

第三方单点登录 (SSO)

由于实施 SSO 解决方案的复杂性,许多公司选择 使用第三方解决方案提供商,以便在多个账号间共享登录状态, 来源。提供方的示例包括 Okta、Ping Identity、Google Cloud IAM 或 Microsoft Entra ID。

与第三方提供商合作时,最佳方法是向以下机构寻求指导: 告知提供商第三方 Cookie 变更将如何影响解决方案,以及 他们推荐的服务方法

开源 SSO 解决方案

许多自行维护单点登录解决方案的公司都会使用成熟的单点登录解决方案 业界标准(如 OpenID Connect、OAuth 或 SAML)或已建立的开放式 源项目,例如 Keycloak、WSO2、Auth.js 或 Hydra。

建议您查看提供商的文档,了解 更改 Cookie 可能会影响他们的解决方案, 这个特定的解决方案

自定义内部解决方案

如果您的登录解决方案之前属于某个用例,并且构建了 为逐步淘汰第三方 Cookie 做好准备,详见更多 详细说明如何审核代码并为第三方 Cookie 变更做好准备。

立即采取行动!

如果您的网站属于上述应用场景之一,您可以采用多种解决方案 以解决任何可能的影响 主网域,因此它仅使用第一方 Cookie Related Website Set,以允许在少量 网域,或利用 Federation Credential Management

审核服务并为使用第三方 Cookie 做好准备的时机 现在有了新变化!