【Web开发】查看逐步淘汰第三方 Cookie 对您登录工作流的影响

第三方 Cookie 不仅有效，还可实现跨网站跟踪。Chrome 计划从 2024 年第 1 季度开始限制 1% 的用户使用第三方 Cookie，以方便测试，然后自 2025 年初开始逐步弃用所有用户的第三方 Cookie，但要解决英国竞争和市场管理局 (CMA) 尚未解决的竞争问题。如果您的网站具有依赖第三方 Cookie 的登录流程，则可能会受到此项变更的影响。您必须确保网站准备就绪。

在此页面上，您将找到最可能受影响的登录场景的相关信息，以及可能的解决方案。

如果您的网站仅处理同一网域和子网域（例如 publisher.example 和 login.publisher.example）内的流，则不会使用跨网站 Cookie，并且您的登录流程应该也不会受到逐步淘汰的影响。

但是，如果您的网站使用单独的网域（例如使用 Google 登录或 Facebook 登录）登录，或者您的网站需要跨多个网域或子网域共享用户身份验证，您可能需要对网站进行更改，以确保顺利弃用跨网站 Cookie。

测试与身份相关的用户体验历程

若要测试您的登录流程是否受第三方 Cookie 停用阶段的影响，最好的方法是在启用第三方 Cookie 逐步淘汰测试标志的情况下完成注册、密码恢复、登录和退出流程。

下面是在限制第三方 Cookie 后需要检查的核对清单：

• 用户注册：可以正常创建新帐号。如果使用第三方身份提供方，请检查新帐号的注册是否适用于每次集成。
• 密码恢复：密码恢复功能会按预期运行，从网页界面到人机识别系统，一直到接收密码恢复电子邮件。
• 登录：登录工作流程适用于同一网域，也可在导航到其他网域时使用。请务必测试每个登录集成。
• 退出：退出流程按预期运行，完成退出流程后，用户会保持未登录状态。

此外，您还应测试其他需要用户登录的网站功能在没有跨网站 Cookie 的情况下是否仍可正常运行，尤其是当这些功能涉及加载跨网站资源时。例如，如果您使用 CDN 加载用户个人资料图片，请确保它仍可正常运行。如果您的某些关键用户历程（例如结账）需要登录才能访问，请确保这些历程继续有效。

在接下来的部分中，您将更具体地说明这些流程可能会受到怎样的影响。

联合身份

使用 Google 帐号登录、Facebook 登录和使用 Twitter 登录等登录按钮明确地表明您的网站使用的是联合身份提供方。由于每个联合身份提供方都有自己的实现，因此最好的解决方案是查看提供方的文档或与他们联系以获取进一步指导。

如果您使用的是已弃用的 Google 登录 JavaScript 平台库，可以了解如何迁移到较新的 Google Identity 服务库以进行身份验证和授权。

大多数使用新版 Google Identity 服务库的网站都已准备好弃用第三方 Cookie，因为该库将以静默方式迁移为使用 FedCM 以实现兼容性。我们建议您在启用第三方 Cookie 逐步淘汰测试标志的情况下测试您的网站，并根据需要使用 FedCM 迁移核对清单做好准备。

单独的登录网域

某些网站仅用于对不符合同网站 Cookie 条件的用户进行身份验证，例如网站对主网站使用 example.com，对登录流程使用 login.example，这可能需要访问第三方 Cookie，以确保用户在这两个网域上都通过了身份验证。

对于这种情况，可能的迁移路径包括：

• 更新以使用第一方（“同网站”）Cookie：更改网站基础架构，使登录流程托管在主网站所在的网域（或子网域）上，从而仅使用第一方 Cookie。此过程可能需要更多工作量，具体取决于基础架构的设置方式。
• 使用 Related Website Set (RWS)：Related Website Set 支持在一小部分相关网域之间限制跨网站 Cookie 访问权限。RWS 是一种 Privacy Sandbox API，旨在支持此用例。但是，RWS 仅支持在有限数量的网域之间进行跨网站 Cookie 访问。
• 如果您要跨 5 个以上的关联网域对用户进行身份验证，请探索 FedCM：联合凭据管理 (FedCM) 可让身份提供方依赖 Chrome 处理与身份相关的流程，而无需第三方 Cookie。在您的情况下，您的“登录网域”可以充当 FedCM 身份提供方，并可用于跨其他网域对用户进行身份验证。

多个网域

当企业在不同网域或子网域上托管多个产品时，它可能希望在这些产品之间共享用户会话，这种情况可能需要在多个网域之间访问第三方 Cookie。

在这种情况下，将所有产品托管在同一网域下通常是不切实际的。在这种情况下，可能的解决方案包括：

• 使用 Related Website Set：在一小部分相关网域之间需要跨网站 Cookie 访问时。
• 使用联合凭据管理 (FedCM)：如果网域数量庞大，您可以使用单独的登录网域充当身份提供方，并使用 FedCM 跨网站对用户进行身份验证。

登录解决方案

第三方单点登录 (SSO)

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

使用第三方提供商时，最好的方法是向提供商寻求指导，了解逐步淘汰第三方 Cookie 对解决方案有何影响，以及他们针对其服务推荐的方法。

开源 SSO 解决方案

许多公司在维护自己的 SSO 解决方案时，会使用既有的行业标准（例如 OpenID Connect、OAuth 或 SAML）或已创建的开源项目（如 Keycloak、WSO2、Auth.js 或 Hydra）来实现。

我们建议您查看提供商的文档，了解逐步淘汰 Cookie 可能会对他们的解决方案产生什么影响，以及该特定解决方案的最佳迁移路径。

自定义内部解决方案

如果您的登录解决方案属于内部的一种用例，请参阅准备逐步淘汰第三方 Cookie，其中更详细地介绍了如何审核您的代码并为逐步淘汰第三方 Cookie 做好准备。

立即采取行动！

如果您的网站属于上述用例之一，有多种解决方案可用于解决任何可能的影响，例如将身份验证流程移至主网域，使其仅使用第一方 Cookie，使用 Related Website Sets 允许在少数网域之间共享 Cookie，或利用联合凭据管理。

审核服务并为第三方 Cookie 逐步停用做好准备的时刻已经到了！