瀏覽器限制、使用者設定、開發人員標記或企業政策，都可能封鎖第三方 Cookie。
無論是否使用第三方 Cookie，您的網站或服務都必須為所有使用者提供良好的體驗。
這個頁面會說明最可能受到影響的身分識別情境，並提供可能的解決方案。
如果您的網站只處理相同網域和子網域內的流程 (例如 publisher.example 和 login.publisher.example)，就不會使用跨網站 Cookie，登入流程也不會受到第三方 Cookie 變更的影響。
不過，如果您的網站使用獨立網域登入 (例如 Google 登入或 Facebook 登入)，或是網站需要在多個網域或子網域之間共用使用者驗證，您可能需要變更網站，確保順利停用跨網站 Cookie。
常見使用者歷程
許多身分識別工作流程過去都依賴第三方 Cookie。下表列出一些常見的使用者歷程，以及不依賴第三方 Cookie 的潛在解決方案。以下各節將說明這些建議的理由。
常見用途的建議替代 API
表格中的功能仍處於初期開發階段，你的意見回饋十分寶貴，有助於他們規劃未來。請針對這些 API 提供想法：分割式彈出視窗。
| 使用者歷程 | 建議的 API |
|---|---|
| 社群媒體登入 |
識別資訊提供者：實作 FedCM 信賴方：與識別資訊提供者聯絡 |
|
身分識別供應商或自訂解決方案： 相關網站集合 |
|
| 使用者設定檔管理 |
Storage Access API 相關網站組合 CHIPS FedCM + SAA |
|
Storage Access API 相關網站組合 CHIPS FedCM + SAA |
|
| 驗證 |
Storage Access API FedCM Web Authentication API sciencePartitioned Popins |
| 這些情境通常不會有第三方 Cookie 依附元件，因此預期不會受到影響。 |
測試與身分相關的使用者歷程
如要測試登入流程是否受到第三方 Cookie 異動影響，最好的方法是啟用第三方 Cookie 測試標記，然後完成註冊、密碼復原、登入和登出流程。
以下是限制第三方 Cookie 後的檢查清單：
- 使用者註冊：建立新帳戶時一切正常。如果使用第三方身分識別提供者，請確認每個整合項目都能註冊新帳戶。
- 密碼救援：密碼救援功能運作正常，從網頁版 UI 到 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 要求儲存空間存取權時，不需要使用者提示。這樣一來，如果 RP 與 IdP 位於同一個 RWS，就能啟用單一登入。不過，RWS 僅支援在有限數量的網域中存取跨網站 Cookie。
- 使用 Web Authentication API：Web Authentication API 可讓信賴方 (RP) 註冊一組相關來源，並在這些來源中建立及使用憑證。
- 如果您要在超過 5 個相關聯的網域中驗證使用者，請瞭解聯合憑證管理 (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。不過，3-party-app.exampleiframe 嵌入 top-level.example 後會經過分割，無法存取 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 小工具。使用者可透過這個小工具管理資料，例如訂閱付費內容或更新帳單資訊。如要修改使用者資料，嵌入的小工具可能需要在嵌入 website.example 時存取自己的 Cookie。如果這項資料應隔離到 website.example，CHIPS 可協助確保嵌入內容能存取所需資訊。使用 CHIPS 後，subscriptions.example
嵌入 website.example 的小工具就無法存取使用者在其他網站的訂閱資料。
再舉一個例子：streaming.example 的影片嵌入 website.example，而使用者訂閱了 streaming.example Premium，小工具需要知道這項資訊才能停用廣告。如果需要跨多個網站存取同一個 Cookie，且使用者先前已將 streaming.example 視為頂層網站造訪，請考慮使用 Storage Access API；如果 website.example 擁有 streaming.example，請考慮使用相關網站集合。
從 Chrome 131 開始，FedCM 會整合 Storage Access API。整合後，使用者接受 FedCM 提示時，瀏覽器會授予 IdP 嵌入式存取未分割儲存空間的權限。
如要進一步瞭解該選擇哪個 API 來處理特定使用者歷程，請參閱嵌入指南。
其他使用者歷程
不依賴第三方 Cookie 的使用者歷程，不應受到 Chrome 處理第三方 Cookie 方式異動的影響。現有解決方案 (例如第一方環境中的登入、登出或帳戶救援、兩步驟驗證) 應可正常運作。先前已說明潛在的斷裂點。如要進一步瞭解特定 API，請查看 API 狀態頁面。
稽核網站
如果您的網站採用本指南所述的其中一種使用者歷程，請確保網站已做好準備：檢查網站使用第三方 Cookie 的情形、測試是否會發生中斷問題，並改用建議的解決方案。