第三方 Cookie 可能会因浏览器限制、用户设置、开发者标志或企业政策而被屏蔽。
无论第三方 Cookie 是否可用，您都需要确保网站或服务为所有用户提供出色的体验。
在此页面上，您将找到有关最有可能受到影响的身份验证方案的信息，以及可能解决方案的参考信息。
如果您的网站仅处理同一网域和子网域（例如 publisher.example 和 login.publisher.example）内的流程，则不会使用跨网站 Cookie，并且您的登录流程预计不会受到第三方 Cookie 更改的影响。
不过，如果您的网站使用单独的网域进行登录（例如使用 Google 登录或 Facebook 登录），或者您的网站需要在多个网域或子网域之间共享用户身份验证信息，那么您可能需要对网站进行更改，以确保顺利过渡到不使用跨网站 Cookie 的状态。
常见用户体验历程
从历史上看，许多身份验证工作流程都依赖于第三方 Cookie。下表列出了一些常见的用户转化历程，以及每种转化历程的潜在解决方案（不依赖于第三方 Cookie）。以下部分将说明这些建议的理由。
针对常见使用场景的推荐替代 API
的 API处于早期开发阶段。您的反馈非常宝贵，有助于塑造他们的未来。分享您对这些 API 的看法：Partitioned Popins。
| 用户转化历程 | 推荐的 API |
|---|---|
| 社交账号登录 |
对于身份提供方：实现 FedCM 对于信赖方：与您的身份提供方联系 |
|
对于身份提供方或自定义解决方案： Related Website Sets |
|
| 用户个人资料管理 |
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。这可能需要付出更多精力，具体取决于基础架构的设置方式。
- 使用 Related Website Set (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 Credentials Management (FedCM)：FedCM 使身份提供方能够依靠 Chrome 来处理与身份相关的流程，而无需使用第三方 Cookie。在您的使用情形中，“登录网域”可以充当 FedCM 身份提供方，用于对其他网域中的用户进行身份验证。
来自嵌入内容的身份验证
假设 top-level.example 上嵌入了 3-party-app.example iframe。在 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 服务库的网站都已不再依赖第三方 Cookie，因为该库会静默迁移到使用 FedCM 以实现兼容性。我们建议您在启用第三方 Cookie 淘汰测试标志的情况下测试您的网站，并在需要时使用 FedCM 迁移核对清单做好准备。
从嵌入内容访问和修改用户数据
嵌入式内容通常用于访问或管理用户个人资料或订阅数据等用户历程。
例如，用户可能会登录嵌入了 subscriptions.example widget 的 website.example。借助此 widget，用户可以管理自己的数据，例如订阅付费内容或更新账单信息。如需修改用户数据，嵌入式 widget 在嵌入到 website.example 时可能需要访问自己的 Cookie。如果需要将此数据隔离到website.example，CHIPS 可以帮助确保嵌入内容能够访问所需的信息。借助 CHIPS，嵌入在 website.example 上的 subscriptions.example widget 将无法访问用户在其他网站上的订阅数据。
再考虑一种情况：streaming.example 中的视频嵌入在 website.example 中，用户拥有 streaming.example Premium 订阅，widget 需要知道这一点才能停用广告。如果需要在多个网站上访问同一 Cookie，请考虑使用 Storage Access API（如果用户之前曾将 streaming.example 作为顶级网站访问过），以及相关网站集（如果 website.example 集拥有 streaming.example）。
从 Chrome 131 开始，FedCM 已与 Storage Access API 集成。通过此集成，当用户接受 FedCM 提示时，浏览器将授予 IdP 嵌入对非分区存储空间的访问权限。
如需详细了解应选择哪个 API 来处理包含嵌入式内容的特定用户体验，请参阅嵌入指南。
其他用户体验历程
不依赖第三方 Cookie 的用户体验不应受到 Chrome 处理第三方 Cookie 方式变化的影响。现有解决方案（例如第一方环境中的登录、退出或账号恢复）以及 2FA 应该可以正常运行。之前已介绍过潜在的断裂点。如需详细了解特定 API，请查看 API 状态页面。
审核您的网站
如果您的网站实现了本指南中描述的某个用户历程，您需要确保网站已做好准备：评估网站的第三方 Cookie 使用情况、测试是否存在中断情况，并过渡到推荐的解决方案。