Chrome 计划推出一种可供用户选择的新体验，其中涉及第三方 Cookie。您需要为选择在不使用第三方 Cookie 的情况下浏览网页的用户做好准备。
在本页面上，您可以找到有关最有可能受到影响的身份验证场景的信息，以及可能的解决方案的参考信息。
如果您的网站仅处理同一网域和子网域（例如 publisher.example 和 login.publisher.example）内的流程，则不会使用跨网站 Cookie，并且您的登录流程预计不会受到第三方 Cookie 更改的影响。
不过，如果您的网站使用单独的网域进行登录（例如使用 Google 登录或 Facebook 登录），或者您的网站需要跨多个网域或子网域共享用户身份验证信息，您可能需要对网站进行更改，以确保顺利停用跨网站 Cookie。
常见用户体验历程
过去，许多身份工作流都依赖于第三方 Cookie。下表列出了一些常见的用户历程，以及针对这些历程的潜在解决方案（这些解决方案不依赖于第三方 Cookie）。以下部分将说明这些建议的理由。
适用于常见用例的推荐替代 API
| 用户体验历程 | 推荐的 API |
|---|---|
| 社交登录 |
对于身份提供方：实现 FedCM 对于依赖方：与您的身份提供方联系 |
| 前端频道退出 | 对于身份提供方：实现 FedCM |
|
对于身份提供方或自定义解决方案： 相关网站集 |
|
| 用户个人资料管理 |
Storage Access API 相关网站集 CHIPS FedCM + SAA |
|
Storage Access API 相关网站集 CHIPS FedCM + SAA |
|
| 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 上实现 SSO。不过，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 服务库以进行身份验证和授权。
由于该库会静默迁移到使用 FedCM 以实现兼容性，因此大多数使用较新版 Google Identity 服务库的网站已不再依赖第三方 Cookie。我们建议您启用第三方 Cookie 逐步淘汰测试标志来测试您的网站，并根据需要使用 FedCM 迁移核对清单进行准备。
访问和修改嵌入内容中的用户数据
嵌入式内容通常用于用户体验历程，例如访问或管理用户个人资料或订阅数据。
例如，用户可能会登录 website.example，其中嵌入了 subscriptions.example 微件。借助此微件，用户可以管理自己的数据，例如订阅付费内容或更新结算信息。为了修改用户数据，嵌入的微件在嵌入到 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 通信。此功能已停用，但如果您对此功能感兴趣或有需要，我们建议您查看初始提案，并与我们分享您的反馈。
其他用户体验历程
不依赖第三方 Cookie 的用户转化历程不应受到 Chrome 处理第三方 Cookie 方式变化的影响。现有解决方案（例如在第一方环境中登录、退出或账号恢复、2FA）应能按预期运行。我们之前介绍了可能出现断点的位置。如需详细了解特定 API，请查看 API 状态页面。请通过 goo.gle/report-3pc-broken 报告您遇到的所有故障。您还可以提交反馈表单，或在 GitHub 的 Privacy Sandbox 开发者支持代码库中提交问题。
审核您的网站
如果您的网站实现了本指南中所述的某种用户体验历程，您需要确保网站做好准备：评估您网站的第三方 Cookie 使用情况、测试是否会出现中断，并改用建议的解决方案。