Chrome 將推出第三方 Cookie 的新功能，讓使用者自行選擇瀏覽體驗。您必須為選擇不使用第三方 Cookie 的使用者做好網站準備。
本頁面提供最有可能受到影響的身分驗證情境資訊，以及可能的解決方案參考。
如果您的網站只處理相同網域和子網域 (例如 publisher.example 和 login.publisher.example) 中的流程，就不會使用跨網站 Cookie，且登入流程不太可能受到第三方 Cookie 變更的影響。
不過，如果您的網站使用不同的網域進行登入 (例如使用 Google 登入或 Facebook 登入)，或是您的網站需要在多個網域或子網域中共用使用者驗證，您可能需要對網站進行變更，確保順利移除跨網站 Cookie。
常見的使用者歷程
以往許多身分驗證工作流程都仰賴第三方 Cookie。下表列出一些常見的使用者歷程，以及每個歷程不依賴第三方 Cookie 的潛在解決方案。以下各節將說明這些建議的原因。
常見用途的建議替代 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) 和儲存空間存取 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 小工具。使用者可透過這個小工具管理資料，例如訂閱付費內容或更新帳單資訊。為了修改使用者資料，嵌入的 Widget 可能需要在嵌入 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 的情形、測試是否會造成服務中斷，並改用建議的解決方案。