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 |
|
| 驗證 |
Storage Access API FedCM Web Authentication API science分割的彈出式視窗 |
| 這些情況通常沒有第三方 Cookie 依附元件，因此不會受到影響。 |
測試與身分相關的使用者歷程
如要測試登入流程是否受到第三方 Cookie 變更的影響，最好的方法就是啟用第三方 Cookie 測試標記，並完成註冊、密碼重設、登入和登出流程。
以下是限制第三方 Cookie 後的檢查清單：
- 使用者註冊：建立新帳戶的功能運作正常。如果使用第三方身分識別資訊提供者，請確認每個整合項目都能註冊新帳戶。
- 密碼救援：密碼救援功能正常運作，從網頁版 UI 到 CAPTCHA，再到收到密碼救援電子郵件。
- 登入：登入工作流程適用於同一個網域，以及前往其他網域時。請務必測試每個登入整合功能。
- 登出：登出程序正常運作，使用者在登出流程結束後仍處於登出狀態。
您也應測試其他需要使用者登入的網站功能，確保在沒有跨網站 Cookie 的情況下仍能正常運作，尤其是涉及載入跨網站資源的功能。舉例來說，如果您使用 CDN 載入使用者個人資料圖片，請確認這項功能仍可正常運作。如果您有關鍵使用者旅程 (例如結帳) 需要登入，請務必確保這些旅程能繼續運作。
登入解決方案
本節將進一步說明這些流程可能受到的影響。
第三方單一登入 (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 上使用 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 來處理含有嵌入內容的特定使用者歷程，請參閱嵌入指南。
前端管道登出
前端登出機制可讓使用者在登出某項服務時，一併登出所有相關應用程式。OIDC 的前端登出功能需要 IdP 嵌入多個依賴方 (RP) iframe，這些 iframe 會依賴 RP 的 Cookie。
如果您的解決方案需要仰賴身分識別提供者，可能需要進行一些小幅變更 (例如程式庫升級)。如需進一步指引，請與您的身分識別資訊提供者聯絡。
為因應這項用途，FedCM 嘗試使用 logoutRPs 功能。這可讓 IdP 登出使用者先前已核准 RP-IdP 通訊的任何 RP。這項功能已不再提供，但如果您對這項功能感興趣或有需要，歡迎參考初始提案，並提供意見回饋。
其他使用者歷程
不依賴第三方 Cookie 的使用者歷程，不應受到 Chrome 處理第三方 Cookie 方式異動的影響。現有解決方案 (例如在第一方情境中登入、登出或復原帳戶) 和 2FA 應可正常運作。我們先前已說明潛在的破壞點。如要進一步瞭解特定 API，請查看 API 狀態頁面。請前往 goo.gle/report-3pc-broken 回報任何服務中斷情形。您也可以提交意見回饋表單，或是在 GitHub 的 Privacy Sandbox 開發人員支援存放區中回報問題。
稽核網站
如果您的網站實作本指南所述的任一使用者歷程，您需要確保網站已做好準備：檢查網站使用第三方 Cookie 的情形、測試是否有中斷情形，然後改用建議的解決方案。