如何處理瀏覽器中的協力廠商 Cookie 封鎖
許多瀏覽器都會封鎖「協力廠商 Cookie」，即瀏覽器網址列中所顯示網域以外的網域要求 Cookie。 這些 Cookie 也稱為「跨網域 Cookie」。 此封鎖會中斷隱含流程，且需要新的驗證模式才能成功登入使用者。 在 Microsoft 身分識別平台中，使用具有程式碼交換的證明金鑰 (PKCE) 的授權流程和重新整理權杖，以便在協力廠商 Cookie 受到封鎖時讓使用者保持登入。 相較於隱含流程，建議使用具有程式碼交換的證明金鑰的授權碼流程。
什麼是智慧型手機追蹤保護 (ITP) 和 Privacy Sandbox？
Apple Safari 有一個預設開啟的隱私權保護功能，稱為智慧型追蹤保護或 ITP。 Chrome 具有名為 Privacy Sandbox 的瀏覽器隱私權計畫。 這些計畫包含許多不同瀏覽器的隱私權工作，而且具有不同的時間軸。 這兩項工作都會封鎖跨網域要求的「協力廠商」Cookie，Safari 和 Brave 則預設封鎖協力廠商 Cookie。 Chrome 最近宣布，他們預設會開始 封鎖協力廠商 Cookie。 Privacy Sandbox 包含 分割儲存體 以及協力廠商 Cookie 封鎖的變更。
使用者追蹤的常見形式，是將 iframe 載入背景中的協力廠商網站中，並使用 Cookie 讓使用者跨網際網路相互關聯。 可惜的是，此模式也是在單頁應用程式 (SPA) 中實作隱含流程的標準方式。 封鎖協力廠商 Cookie 來保護使用者隱私權的瀏覽器也可以封鎖 SPA 的功能。 由於封鎖協力廠商 Cookie 以及與此相關聯的安全性風險，因此不再建議在 SPA 中使用隱含流程。
本文中所述的解決方案適用於所有的瀏覽器，以及任何封鎖協力廠商 Cookie 的地方。
解決方案概觀
若要繼續在 SPA 中驗證使用者，應用程式開發人員必須使用授權碼流程。 在授權碼流程中，識別提供者會發出程式碼，而 SPA 會兌換存取權杖和重新整理權杖的程式碼。 應用程式需要新的權杖時，可以使用重新整理權杖流程來取得新的權杖。 適用於 JavaScript v2.0 和更新版本的 Microsoft 驗證程式庫 (MSAL) 會實作 SPA 的授權碼流程，而次要更新則是 MSAL.js 1.x 的直接取代項目。 請參閱 移轉指南，將 SPA 從隱含移至授權碼流程。
針對 Microsoft 身分識別平台，SPA 和原生用戶端會遵循類似的通訊協定指導：
- 使用 PKCE 程式碼挑戰
- PKCE 是 Microsoft 身分識別平台上 SPA 的「必要項目」。 PKCE 是原生和保密用戶端的「建議項目」。
- 不使用用戶端密碼
SPA 還有兩個限制：
- 重新導向 URI 必須標示為類型
spa，才能在登入端點上啟用 CORS。 - 透過授權碼流程發出至
spa重新導向 URI 的重新整理權杖會有 24 小時的存留期，而不是 90 天的存留期。
效能與 UX 的影響
使用隱含流程的某些應用程式會嘗試使用 prompt=none 開啟登入 iframe，而不進行重新導向。 在大部分的瀏覽器中，此要求會以目前登入使用者的權杖回應 (假設已授與同意)。 此模式代表應用程式不需要重新導向至完整的頁面，即可讓使用者登入，並且改善效能和使用者體驗，即使用者造訪網頁時，就已是登入狀態。 協力廠商 Cookie 遭到封鎖時，iframe 中的 prompt=none 不再是選項，因此應用程式必須調整其登入模式，以便發出授權碼。
如果沒有協力廠商 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 與父應用程式之間的單一登入。 如需詳細資訊，請參閱 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 的前端通道登出限制
從 SPA 登出使用者時，MSAL.js 建議使用 快顯或重新導向登出方法。 雖然這會清除伺服器和瀏覽器儲存體上的驗證工作階段，但如果無法存取協力廠商 Cookie，則會存在並非所有同盟應用程式都會同時看到登出的風險。 這是 OpenID Front-Channel Logout 1.0 規格的已知限制。 對使用者而言，相同使用者之其他應用程式的現有存取權杖將繼續有效，直到過期時間為止。 使用者可以在 A 分頁中登出應用程式 A，但在存取權杖剩餘的有效時間內，B 分頁中的應用程式 B 仍會顯示為登入。 應用程式 B 的權杖過期，並呼叫伺服器來取得新的權杖時，應用程式 B 會從伺服器收到工作階段已過期的回應，並提示使用者進行驗證。
Microsoft 的登出頁面和 網際網路隱私權最佳做法 建議使用者在登出應用程式之後關閉所有瀏覽器視窗。
後續步驟
如需授權碼流程和 MSAL.js 的詳細資訊，請參閱：