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 |
|
| 驗證 |
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) 和儲存空間存取 API (SAA)：RWS 可在少數相關網域之間提供有限的跨網站 Cookie 存取權。使用 RWS 時，您無須透過 Storage Access API 要求存取儲存空間，也不需要顯示使用者提示。這樣一來，系統就能在與 IdP 位於相同 RWS 的 RP 上進行單一登入。不過，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 的呼叫是透過內嵌程式碼 (而非彈出式視窗) 呼叫。
這個流程的另一個建議解決方案「 分區彈出式視窗」，目前正在實作中。
社群媒體登入
使用 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 來處理含有嵌入內容的特定使用者歷程，請參閱嵌入指南。
前端管道登出
前端登出機制可讓使用者在登出某項服務時，一併登出所有相關應用程式。OIDC 的前端登出功能需要 IdP 嵌入幾個依賴 RP 的 Cookie 的依賴方 (RP) iframe。
如果您的解決方案需要使用識別資訊提供者，可能需要小幅變更 (例如昇級程式庫)。如需進一步指引，請與您的身分識別資訊提供者聯絡。
為因應這項用途，FedCM 嘗試使用 logoutRPs 功能。這可讓 IdP 登出使用者先前已核准 RP-IdP 通訊的任何 RP。這項功能已不再提供，但如果您對這項功能感興趣或有需要，歡迎參考初始提案，並提供意見回饋。
其他使用者歷程
不依賴第三方 Cookie 的使用者歷程，不應受到 Chrome 處理第三方 Cookie 方式異動的影響。現有的解決方案 (例如，在第一方情境下進行登入、登出或帳戶救援) 應該能正常運作。我們先前已說明潛在的破壞點。如要進一步瞭解特定 API，請參閱 API 狀態頁面。請前往 goo.gle/report-3pc-broken 回報任何服務中斷情形。你也可以在 Privacy Sandbox 開發人員支援存放區中提交意見回饋表單，或在 GitHub 上回報問題。
稽核網站
如果您的網站實作本指南所述的任一使用者歷程，您需要確保網站已做好準備：檢查網站使用第三方 Cookie 的情形、測試是否有中斷情形，然後改用建議的解決方案。