Chrome 计划推出一种可供用户选择的新体验，以便使用第三方 Cookie。您需要为选择在不使用第三方 Cookie 的情况下浏览的用户做好网站准备。
本页面介绍了最可能受到影响的身份场景以及可能的解决方案。
如果您的网站仅处理同一网域和子网域（例如 publisher.example 和 login.publisher.example）内的流程，则不会使用跨网站 Cookie，并且您的登录流程预计不会受到第三方 Cookie 更改的影响。
不过，如果您的网站使用单独的网域进行登录（例如使用 Google 登录或 Facebook 登录），或者您的网站需要跨多个网域或子网域共享用户身份验证信息，您可能需要对网站进行更改，以确保顺利停用跨网站 Cookie。
常见用户体验历程
过去，许多身份工作流都依赖于第三方 Cookie。此表格列出了一些常见的用户体验历程以及针对各个阶段的可能不依赖第三方 Cookie 的潜在解决方案。以下部分将说明这些建议的理由。
适用于常见用例的推荐替代 API
| 用户体验历程 | 推荐的 API |
|---|---|
| 社交媒体登录 |
对于身份提供方：实现 FedCM 对于依赖方：与您的身份提供方联系 |
| 退出前置频道 | 对于身份提供方：实现 FedCM |
|
对于身份提供方或自定义解决方案： 相关网站集 |
|
| 用户个人资料管理 |
Storage Access API 相关网站集 CHIPS FedCM |
|
Storage Access API 相关网站集 CHIPS FedCM |
|
| Authentication |
Storage Access API FedCM Web Authentication API science分区弹出窗口 |
| 这些场景通常没有第三方 Cookie 依赖项，因此预计不会受到影响。 |
测试与身份相关的用户体验历程
如需测试您的登录流程是否受到第三方 Cookie 更改的影响，最好的方法是启用第三方 Cookie 测试标志，然后完成注册、密码恢复、登录和退出流程。
以下是限制第三方 Cookie 后需要检查的事项清单：
- 用户注册：可以按预期创建新账号。如果使用第三方身份提供方，请检查是否能为每种集成注册新账号。
- 密码恢复：密码恢复功能按预期运行，从网页界面、CAPTCHA 到接收密码恢复电子邮件。
- 登录：登录工作流在同一网域内以及在导航到其他网域时均可使用。请务必测试每项登录集成。
- 退出登录：退出登录流程按预期运行，用户在退出登录流程后仍处于退出登录状态。
您还应测试在没有跨网站 Cookie 的情况下，需要用户登录的其他网站功能是否仍然可以正常运行，尤其是涉及加载跨网站资源的功能。例如，如果您使用 CDN 加载用户个人资料图片，请确保该方法仍然有效。如果您有关键的用户历程（例如结账）需要用户登录才能完成，请确保这些历程能够继续正常运行。
登录解决方案
在本部分中，您将更具体地了解这些流可能会受到怎样的影响。
第三方单点登录 (SSO)
借助第三方单点登录 (SSO)，用户可以在一个平台上使用一组凭据进行身份验证，然后访问多个应用和网站，而无需重新输入登录信息。由于实现 SSO 解决方案的复杂性，许多公司选择使用第三方解决方案提供商，以便在多个来源之间共享登录状态。提供商示例包括 Okta、Ping Identity、Google Cloud IAM 或 Microsoft Entra ID。
如果您的解决方案依赖于第三方提供商，您可能需要进行一些细微更改（例如库升级）。最佳做法是向提供商寻求指导，了解第三方 Cookie 依赖项如何影响解决方案，以及他们为其服务推荐的做法。某些提供商会静默迁移，不再使用第三方 Cookie，在这种情况下，依赖方无需更新。
多个网域
某些网站仅使用其他网域来验证不符合使用同网站 Cookie 条件的用户，例如，某个网站使用 example.com 作为主网站，使用 login.example 作为登录流程，这可能需要访问第三方 Cookie 以确保在两个网域中都对用户进行身份验证。
某些商家可能会在不同的网域或子网域上托管多个产品。此类解决方案可能希望跨这些产品共享用户会话，这种情况下可能需要在多个网域之间访问第三方 Cookie。
对于此情况，可能的迁移路径如下：
- 更新为使用第一方（“同网站”）Cookie：更改网站基础架构，使登录流程托管在与主网站相同的网域（或子网域）上，并且只使用第一方 Cookie。这可能需要更多工作量，具体取决于基础架构的设置方式。
- 使用相关网站集 (RWS) 和 Storage Access API (SAA)：RWS 支持在少量相关网域之间进行有限的跨网站 cookie 访问。借助 RWS，使用 Storage Access API 请求存储空间访问权限时不需要用户提示。这样一来，与 IdP 位于同一 RWS 的 RP 就可以进行单点登录了。不过，RWS 仅支持对有限数量网域中的跨网站 cookie 进行访问。
- 使用 Web Authentication API：Web Authentication API 允许依赖方 (RP) 注册一组数量有限的相关源站，您可以在其中创建和使用凭据。
- 如果您要对 5 个以上关联网域中的用户进行身份验证，请探索 Federated Credential Management (FedCM)：借助 FedCM，身份提供方可以依赖 Chrome 来处理与身份相关的流程，而无需第三方 Cookie。在您的示例中，“登录网域”可以充当 FedCM 身份提供方，用于对您其他网域中的用户进行身份验证。
嵌入身份验证
假设 3-party-app.example iframe 嵌入在 top-level.example 中。在 3-party-app.example 上，用户可以使用 3-party-app.example 凭据或其他第三方提供方的凭据登录。
用户点击“登录”，然后在 3-party-app.example 弹出式窗口中进行身份验证。3-party-app.example 弹出式窗口会设置第一方 Cookie。不过，嵌入在 top-level.example 上的 3-party-app.example iframe 已经过分区，无法访问在 3-party-app.example 上的第一方上下文中设置的 Cookie。
如果用户从 top-level.example 重定向到 3-party-app.example 然后返回，也会出现同样的问题。Cookie 是在 3-party-app.example 网站的第一方环境中写入的，但已分区，无法在 3-party-app.example iframe 中访问。
如果用户在顶级环境中访问了嵌入的来源，则 Storage Access API 是一个不错的解决方案。
若要停止使用依赖第三方 Cookie 的解决方案，我们建议身份提供方采用 FedCM API，并且从嵌入内部（而不是弹出式窗口）调用 FedCM。
我们还提出了另一种解决方案（分区弹出式窗口），目前正在实施中。
社交登录
使用 Google 账号登录、Facebook 登录和使用 Twitter 账号登录等登录按钮是网站使用联合身份提供方的明确标志。每个联合身份提供程序都有自己的实现。
如果您使用的是已弃用的 Google 登录 JavaScript 平台库，可以了解如何迁移到较新的 Google Identity 服务库以进行身份验证和授权。
大多数使用新版 Google Identity Services 库的网站已经不再对第三方 Cookie 的依赖，因为该库会自动迁移为使用 FedCM 以实现兼容性。我们建议您启用第三方 Cookie 逐步淘汰测试标志来测试您的网站，并根据需要使用 FedCM 迁移核对清单进行准备。
通过嵌入访问和修改用户数据
嵌入式内容通常用于用户体验历程，例如访问或管理用户个人资料或订阅数据。
例如，用户可能会登录 website.example，其中嵌入了 subscriptions.example widget。借助此微件，用户可以管理自己的数据，例如订阅付费内容或更新结算信息。为了修改用户数据，嵌入的微件在嵌入到 website.example 时可能需要访问自己的 Cookie。如果此类数据应隔离到 website.example，CHIPS 可以帮助确保嵌入内容可以访问所需的信息。借助 CHIPS，嵌入在 website.example 上的 subscriptions.example 微件将无法访问用户在其他网站上的订阅数据。
再考虑另一种情况：streaming.example 上的视频嵌入到 website.example 中，并且用户订阅了 streaming.example 高级服务，该 widget 需要知道这一点才能停用广告。如果需要跨多个网站访问同一 Cookie，请考虑使用 Storage Access API（如果用户之前以顶级网站的身份访问了 streaming.example）或 相关网站集（如果 website.example 的集拥有 streaming.example）。
从 Chrome 131 开始，FedCM 与 Storage Access API 集成。通过此集成，当用户接受 FedCM 提示时，浏览器会向 IdP 授予对未分区的存储空间的嵌入式访问权限。
如需详细了解应选择哪个 API 来处理包含嵌入内容的特定用户体验历程，请参阅嵌入指南。
前端渠道退出
正向通道退出是一种机制，可让用户在退出某项服务时退出所有相关应用。OIDC 的前端登出功能要求 IdP 嵌入多个依赖方 (RP) iframe，这些 iframe 依赖于 RP 的 Cookie。
如果您的解决方案依赖于身份提供方，则可能需要进行细微更改（例如库升级）。如需进一步指导，请与您的身份提供商联系。
为了解决此用例，FedCM 对 logoutRPs 功能进行了实验。这样一来，IdP 便可以退出用户之前已批准 RP-IdP 通信的任何 RP。此功能现已停用，但我们建议您查看初始提案，如果您对此功能感兴趣或有需要，请与我们分享您的反馈。
其他用户体验历程
Chrome 处理第三方 Cookie 的方式变化不会对不依赖第三方 Cookie 的用户体验历程产生影响。现有解决方案（例如在第一方环境中登录、退出或账号恢复、2FA）应能按预期运行。之前介绍过潜在的故障点。如需详细了解特定 API，请查看 API 状态页面。如遇到任何故障，请前往 goo.gle/report-3pc-broken 进行报告。您还可以提交反馈表单或在 GitHub 上的 Privacy Sandbox 开发者支持存储库中提交问题。
审核您的网站
如果您的网站实现了本指南中所述的某种用户体验历程，您需要确保网站做好准备：评估您网站的第三方 Cookie 使用情况、测试是否存在中断问题，并改用建议的解决方案。