如何在瀏覽器中處理第三方 Cookie 封鎖

許多瀏覽器會封鎖 第三方 Cookie、對瀏覽器網址列中所顯示網域以外的網域要求的 Cookie。 這些 Cookie 也稱為 跨網域 Cookie。 此區塊會中斷隱含流程,而且需要新的驗證模式才能成功登入使用者。 在 Microsoft 身分識別平台 中,我們會使用授權流程搭配驗證密鑰進行程式碼交換 (PKCE) 和重新整理令牌,以在封鎖第三方 Cookie 時讓使用者保持登入。

什麼是智慧型手機追蹤保護 (ITP) 和隱私權沙箱?

Apple Safari 具有稱為智慧型手機追蹤保護或 ITP 的預設隱私權保護功能。 Chrome 有名為 Privacy Sandbox瀏覽器隱私權計畫。 這些計劃包含瀏覽器的許多不同瀏覽器隱私權工作,而且具有不同的時程表。 這兩項工作都會封鎖跨網域要求的「第三方」Cookie,預設會封鎖Safari和 Brave 封鎖第三方Cookie。 Chrome 最近宣佈,他們預設會開始封鎖第三方 Cookie。 隱私權沙盒包含分割記憶體的變更,以及第三方 Cookie 封鎖。

用戶追蹤的常見形式是將 iframe 載入背景中的第三方網站,並使用 Cookie 將使用者跨因特網相互關聯來完成。 不幸的是,此模式也是在單頁應用程式中實 作隱含流程 的標準方式。 封鎖第三方 Cookie 以保護用戶隱私權的瀏覽器也可以封鎖 SPA 的功能。

本文中所述的解決方案適用於所有瀏覽器,或封鎖第三方 Cookie 的任何位置。

解決方案的概觀

若要繼續驗證 SPA 中的使用者,應用程式開發人員必須使用 授權碼流程。 在驗證碼流程中,識別提供者會發出程式代碼,SPA 會兌換存取令牌和重新整理令牌的程序代碼。 當應用程式需要新的令牌時,它可以使用重新 整理令牌流程 來取得新的令牌。 適用於 JavaScript v2.0 和更新版本的 Microsoft 驗證連結庫 (MSAL) 會實作 SPA 的授權碼流程,而次要更新則是 MSAL.js 1.x 的卸除取代專案。 請參閱將 SPA 從隱含移至驗證程式代碼流程的移轉指南

針對 Microsoft 身分識別平台,SPA 和原生用戶端遵循類似的通訊協定指引:

  • 使用 PKCE 程式代碼挑戰
    • Microsoft 身分識別平台 上的 SPA 需要 PKCE。 原生 和機密客戶端建議 使用 PKCE。
  • 不使用客戶端密碼

SPA 還有兩個限制:

  • 重新導向 URI 必須標示為類型 spa ,才能在登入端點上啟用 CORS。
  • 重新整理透過授權碼流程發出的令牌,以 spa 重新導向 URI 的存留期為 24 小時,而不是 90 天的存留期。

Diagram showing the OAuth 2 authorization code flow between a single-page app and the security token service endpoint.

效能和UX含意

某些使用隱含流程的應用程式會嘗試登入而不重新導向,方法是使用 prompt=none開啟登入 iframe。 在大部分的瀏覽器中,此要求會以目前登入使用者的令牌回應(假設已授與同意)。 此模式表示應用程式不需要完整頁面重新導向來登入使用者、改善效能和用戶體驗 - 使用者瀏覽網頁並已登入。 因為 prompt=none 當第三方 Cookie 遭到封鎖時,在 iframe 中不再是選項,因此應用程式必須調整其登入模式,以發出授權碼。

如果沒有第三方 Cookie,有兩種方式可以完成登入:

  • 完整頁面重新導向
    • 在第一次載入 SPA 時,如果使用者還沒有會話存在,請將使用者重新導向至登入頁面(或會話已過期)。 用戶的瀏覽器會流覽登入頁面、呈現包含使用者會話的 Cookie,然後重新導向回具有片段中程式碼和令牌的應用程式。
    • 重新導向會導致 SPA 載入兩次。 請遵循快取 SPA 的最佳做法,讓應用程式不會完整下載兩次。
    • 請考慮在應用程式中預先載入順序,以檢查登入會話,並在應用程式完全解壓縮並執行 JavaScript 承載之前,重新導向至登入頁面。
  • 快顯
    • 如果完整頁面重新導向的用戶體驗 (UX) 不適用於應用程式,請考慮使用快顯來處理驗證。
    • 當快顯在驗證之後完成重新導向至應用程式時,重新導向處理程式中的程式代碼會將驗證碼和令牌儲存在本機記憶體中,以供應用程式使用。 MSAL.js支持驗證的彈出視窗,就像大部分的連結庫一樣。
    • 瀏覽器正在減少對快顯的支援,因此它們可能不是最可靠的選項。 建立快顯之前,可能需要使用者與 SPA 互動,才能滿足瀏覽器需求。

Apple 將快顯方法 描述為暫時的相容性修正,以提供第三方 Cookie 的原始視窗存取權。 雖然 Apple 未來可能會移除此許可權的轉移,但不會影響這裡的指導方針。

在這裡,彈出視窗會用來做為登入頁面的第一方導覽,以便找到會話,並提供驗證碼。 這應該會繼續走向未來。

當第三方 Cookie 遭到封鎖時,開發人員可以繼續使用prompt=none,期望他們看到較高的interacion_required錯誤率。 如果發生無訊息令牌擷取期間失敗,建議一律有 互動式方法後援

使用 iframe

Web 應用程式中的常見模式是使用 iframe 將一個應用程式內嵌在另一個應用程式內:最上層框架會處理驗證使用者,而裝載在 iframe 中的應用程式可以信任使用者已登入,使用隱含流程以無訊息方式擷取令牌。 不過,不論第三方 Cookie 是在瀏覽器中啟用或封鎖,這項假設有幾項注意事項。

當第三方 Cookie 遭到封鎖時,無訊息令牌擷取無法再運作 - 內嵌在 iframe 中的應用程式必須切換至使用快顯來存取使用者的會話,因為它無法巡覽至內嵌框架內的登入頁面。

您可以將父應用程式的使用者(帳戶)提示傳遞至 iframed 應用程式,以使用相同原始來源 跨原始 JavaScript 腳本 API 存取的 iframed 應用程式,來達成 iframed 與父應用程式之間的單一登錄。 如需詳細資訊,請參閱 GitHub 上 MSAL.js 存放庫中的 iframed 應用程式中 使用 MSAL.js。

瀏覽器中重新整理令牌的安全性影響

跨網站腳本 (XSS) 攻擊或遭入侵的 JS 套件可能會竊取重新整理令牌,並遠端使用它,直到到期或撤銷為止。 應用程式開發人員負責降低應用程式跨網站腳本的風險。 為了將遭竊重新整理令牌的風險降到最低,SPA 只會發行 24 小時有效的令牌。 24 小時之後,應用程式必須透過最上層框架流覽登入頁面來取得新的授權碼。

這個有限的存留期重新整理令牌模式已選擇為安全性與降級UX之間的平衡。 如果沒有重新整理令牌或第三方 Cookie,授權碼流程(如 OAuth 安全性目前最佳做法草稿所建議)會在需要新的或其他令牌時變得十分繁重。 每個單一令牌都需要完整頁面重新導向或快顯,每次令牌到期時(通常每小時,Microsoft 身分識別平台 令牌)。

用戶類型特定風險降低

並非所有的使用者和應用程式都受到第三方 Cookie 的統一影響。 在某些情況下,由於架構或裝置管理,更新令牌的無訊息呼叫可以在沒有第三方 Cookie 的情況下完成。

針對 受控企業裝置 案例,某些瀏覽器和平臺組合支援 裝置條件式存取。 套用裝置身分識別可將第三方 Cookie 的需求降到最低,因為驗證狀態可能來自裝置而非瀏覽器。

針對 Azure AD B2C 應用程式 案例,客戶可以設定 自定義登入網域 以符合應用程式的網域。 瀏覽器不會在此案例中封鎖第三方 Cookie,因為 Cookie 會保留在相同的網域中(例如 login.contoso.com app.contoso.com)。

沒有第三方 Cookie 的 Front-Channel 註銷限制

從 SPA 註銷使用者時,MSAL.js建議使用 快顯或重新導向註銷方法。 雖然這會清除伺服器和瀏覽器記憶體上的驗證會話,但沒有存取第三方 Cookie 的風險,並非所有同盟應用程式都會同時看到註銷。 這是OpenID Front-Channel Logout 1.0 規格已知限制。 對於用戶來說,對使用者而言,相同使用者之其他應用程式的現有存取令牌將繼續有效,直到到期時間為止。 用戶可以在索引標籤 A 中註銷應用程式 A,但索引標籤 B 中的應用程式 B 仍會顯示為登入,以供存取令牌剩餘的有效時間使用。 當應用程式 B 的權杖到期,並呼叫伺服器以取得新的權杖時,應用程式 B 會從伺服器收到工作階段已過期的回應,並提示使用者進行驗證。

Microsoft 的註銷頁面和 因特網隱私權最佳做法 建議使用者在註銷應用程式之後關閉所有瀏覽器視窗。

下一步

如需授權碼流程和MSAL.js的詳細資訊,請參閱: