第三方 Cookie 的用途有效，但也可以啟用跨網站追蹤功能。Chrome 計劃從 2024 年第 1 季開始，將第三方 Cookie 限制在 2024 年第 1 季，以協助測試，接著逐步淘汰 2025 年初對 100% 使用者全面淘汰的第三方 Cookie，確實解決《英國競爭與市場管理局》(CMA) 其餘的競爭問題。如果網站的登入流程需要依賴第三方 Cookie，這項變更很可能會受影響。您必須確認網站已就緒。
本頁將說明最有可能受到影響的登入情境，以及可能的解決方法。
如果您的網站只處理相同網域和子網域 (例如 publisher.example 和 login.publisher.example) 內的流程，就不會使用跨網站 Cookie，而登入流程也不會因為逐步停用而受到影響。
不過，如果您的網站使用個別的網域登入 (例如使用 Google 登入或 Facebook 登入功能)，或是您的網站需要跨多個網域或子網域共用使用者驗證，則您必須變更網站，才能確保從跨網站 Cookie 順利轉換。
測試與您身分相關的使用者歷程
如要測試登入流程是否會受到第三方 Cookie 階段影響，最好的做法是在啟用第三方 Cookie 逐步淘汰測試標記的情況下，完成註冊、密碼復原、登入和登出流程。
以下列出限制第三方 Cookie 後應檢查的事項：
- 使用者註冊：建立新帳戶。如果您使用第三方識別資訊提供者，請確認每次整合都能註冊新帳戶。
- 密碼復原：密碼復原功能可以正常運作，從網頁版 UI 到 人機驗證 (CAPTCHA) 到接收密碼復原電子郵件。
- 登入：登入工作流程在同一個網域中運作，也可前往其他網域。請務必測試每項登入整合作業。
- 登出：登出程序可以正常運作，並在登出流程後將使用者維持登出狀態。
此外，您也應測試需要使用者登入的其他網站功能是否仍可在沒有跨網站 Cookie 的情況下正常運作，尤其是如果這些功能需要載入跨網站資源時更是如此。舉例來說，如果您使用 CDN 載入使用者個人資料圖片，請確認該方法仍可正常運作。如果有關鍵的使用者歷程 (例如結帳系統需要登入才能存取)，請確保這些歷程可持續運作。
在後續章節中，您將進一步瞭解這些流程可能受到哪些影響。
聯合身分識別
「使用 Google 帳戶登入」、Facebook 登入和以 Twitter 登入等登入按鈕，代表網站使用聯合識別資訊提供者。由於每個聯合識別資訊提供者都有自己的實作方式，因此最好的解決方案就是參閱供應商的說明文件，或洽詢供應商以取得進一步指引。
如果您使用已淘汰的 Google 登入 JavaScript 平台程式庫，可以參閱這篇文章，瞭解如何遷移至新版 Google Identity 服務程式庫，以便驗證及授權。
大多數使用新版 Google Identity 服務程式庫的網站都可以淘汰第三方 Cookie，因為該程式庫會在未通知的情況下遷移，改用 FedCM 來確保相容性。建議您在啟用第三方 Cookie 逐步淘汰測試標記的情況下測試您的網站，並視需要使用 FedCM 遷移檢查清單做好準備。
獨立的登入網域
有些網站只會使用不同的網域來驗證不符合相同網站 Cookie 的使用者資格，例如網站使用 example.com 做為主要網站，而在登入流程中使用 login.example，而這可能需要存取第三方 Cookie，才能確保使用者在兩個網域中已通過驗證。
這種情況可能的遷移路徑如下：
- 更新為使用第一方 (「同網站」) Cookie：變更網站基礎架構，讓登入流程與只使用第一方 Cookie 的網域 (或子網域) 代管，視基礎架構的設定方式而定，這項作業可能需要花費更多心力。
- 使用相關網站集 (RWS)：「相關網站集」可讓少數相關網域之間限制存取有限的跨網站 Cookie。RWS 是為支援這種用途而建構的 Privacy Sandbox API。不過，RWS 僅支援少數網域上的跨網站 Cookie 存取。
- 如要跨超過 5 個相關網域驗證使用者，請探索 FedCM：Federated Credentials Management (FedCM) 可讓識別資訊提供者仰賴 Chrome 來處理身分相關流程，而且不必使用第三方 Cookie。就您的情況而言，「登入網域」可以做為 FedCM 識別資訊提供者，並用來驗證您其他網域的使用者。
多個網域
如果商家有多個由不同網域或子網域代管的產品，可能需要在多個產品之間共用使用者工作階段。在某些情況下，可能需要在多個網域之間存取第三方 Cookie。
在此情況下，在同一個網域下託管所有產品通常並不容易。在這個情況下，可能的解決方案有：
- 使用相關網站集：當一小部分的相關網域之間需要存取跨網站 Cookie 時。
- 使用聯盟憑證管理 (FedCM)：如果網域數量龐大，您可以使用個別的登入網域做為識別資訊提供者，並透過 FedCM 跨網站驗證使用者。
登入解決方案
第三方單一登入 (SSO)
由於實作單一登入 (SSO) 解決方案相當複雜，許多公司選擇採用第三方解決方案供應商來在多個來源之間共用登入狀態。提供者範例包括 Okta、Ping Identity、Google Cloud IAM 或 Microsoft Entra ID。
與第三方供應商合作時，最佳做法是向供應商尋求指引，瞭解逐步淘汰第三方 Cookie 對解決方案的影響，以及對方推薦對服務採取的做法。
開放原始碼單一登入 (SSO) 解決方案
許多公司在維護單一登入 (SSO) 解決方案時，都會使用既定的業界標準，例如 OpenID Connect、OAuth 或 SAML，或是已開發的開放原始碼專案 (例如 Keycloak、WSO2、Auth.js 或 Hydra)。
建議您查看供應商的說明文件，瞭解 Cookie 淘汰作業可能對自家解決方案造成的影響，以及該特定解決方案的最佳遷移路徑。
自訂內部解決方案
如果您的登入解決方案屬於內部用途且屬於內部用途，準備淘汰第三方 Cookie 一文詳細說明瞭如何稽核程式碼，以及如何逐步淘汰第三方 Cookie。
請立即採取行動！
如果您的網站屬於其中一種用途，可以透過多種解決方案因應任何可能的影響，例如將驗證流程移至主要網域，只使用第一方 Cookie、使用相關網站集允許少數網域共用 Cookie，或是使用聯盟憑證管理。
為因應第三方 Cookie 的階段，現在開始稽核您的服務並做好準備了！現在！