第三方 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 science分割的彈出式視窗 |
| 這些情況通常沒有第三方 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，就能使用 SSO。不過，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。不過，嵌入 top-level.example 的 3-party-app.example iframe 已分割，因此無法存取 3-party-app.example 上第一方背景中的 Cookie 組合。
當使用者從 top-level.example 重新導向至 3-party-app.example，然後再重新導向回 top-level.example 時，也會發生相同的問題。Cookie 是在 3-party-app.example 網站的第一方內容中寫入，但已劃分區塊，因此無法在 3-party-app.example iframe 中存取。
如果使用者在頂層情境中造訪嵌入的來源網頁，Storage Access API 就是理想的解決方案。
為了移除依賴第三方 Cookie 的解決方案，我們建議識別資訊提供者採用 FedCM API，並從嵌入項目 (而非彈出式視窗) 呼叫 FedCM。
我們也提出了另一個解決方案，即 Partitioned Popins，目前正在實作中。
社群媒體登入
使用 Google 帳戶登入、Facebook 登入和使用 Twitter 帳戶登入等登入按鈕，是網站使用聯合身分識別提供者的明確徵兆。每個聯合身分識別服務供應器都有自己的實作方式。
如果您使用的是已淘汰的 Google 登入 JavaScript 平台資料庫，可以參閱這篇文章，瞭解如何改用較新的 Google Identity 服務資料庫，以便驗證和授權。
大多數使用較新 Google Identity 服務程式庫的網站已不再依賴第三方 Cookie，因為程式庫會在背景中遷移，改為使用 FedCM 以確保相容性。建議您在啟用第三方 cookie 逐步淘汰測試標記的情況下測試網站，並視需要使用 FedCM 遷移檢查清單進行準備。
存取嵌入內容中的使用者資料並加以修改
嵌入式內容通常用於使用者歷程，例如存取或管理使用者個人資料或訂閱資料。
舉例來說，使用者可能會登入 website.example，該網頁內嵌了 subscriptions.example 小工具。這個小工具可讓使用者管理資料，例如訂閱付費內容或更新帳單資訊。為了修改使用者資料，嵌入的動態小工具可能需要在嵌入 website.example 時存取自己的 Cookie。在需要將這類資料隔離至 website.example 的情況下，CHIPS 可確保內嵌程式碼可以存取所需的資訊。有了 CHIPS，website.example 中嵌入的 subscriptions.example 小工具就不會存取使用者在其他網站上的訂閱資料。
請考慮另一個案例：streaming.example 嵌入 website.example 的影片，而使用者訂閱了 streaming.example 的進階方案，小工具需要知道這項資訊才能停用廣告。如果需要跨多個網站存取相同的 Cookie，如果使用者先前以頂層方式造訪 streaming.example，建議使用 Storage Access API；如果 website.example 集合擁有 streaming.example，則建議使用 相關網站集合。
自 Chrome 131 起，FedCM 已與 Storage Access API 整合。透過這項整合功能，當使用者接受 FedCM 提示時，瀏覽器就會授予 IdP 對未分割儲存空間的嵌入存取權。
如要進一步瞭解如何選擇 API 來處理含有嵌入內容的特定使用者歷程，請參閱嵌入指南。
其他使用者歷程
不仰賴第三方 Cookie 的使用者歷程不應受到 Chrome 處理第三方 Cookie 方式異動的影響。現有解決方案 (例如在第一方情境中登入、登出或帳戶復原) 和 2FA 應可正常運作。我們先前已說明潛在的破損點。如要進一步瞭解特定 API，請查看 API 狀態頁面。請將遇到的任何中斷情形回報至 goo.gle/report-3pc-broken。您也可以提交意見回饋表單，或是在 GitHub 的 Privacy Sandbox 開發人員支援存放區中回報問題。
稽核網站
如果您的網站實作本指南所述的其中一個使用者歷程，您需要確保網站已做好準備：檢查網站使用第三方 Cookie 的情形、測試中斷情形，然後改用建議的解決方案。