如何處理瀏覽器中的第三方 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 的 Front-Channel 登出限制
從 SPA 登出使用者時，MSAL.js建議使用 快顯或重新導向登出方法。 雖然這會清除伺服器和瀏覽器儲存體上的驗證工作階段，但沒有存取第三方 Cookie 的風險，並非所有同盟應用程式都會同時看到登出。 這是 OpenID Front-Channel Logout 1.0 規格 的已知限制。 對於使用者來說，對使用者而言，相同使用者之其他應用程式的現有存取權杖將繼續有效，直到到期時間為止。 使用者可以在 A 分頁中登出應用程式 A，但 B 分頁中的應用程式 B 仍會顯示為登入，以供存取權杖剩餘的有效時間使用。 當應用程式 B 的權杖到期，並呼叫伺服器以取得新的權杖時，應用程式 B 會從伺服器收到工作階段已過期的回應，並提示使用者進行驗證。
Microsoft 的登出頁面和 網際網路隱私權最佳做法 建議使用者在登出應用程式之後關閉所有瀏覽器視窗。
下一步
如需授權碼流程和 MSAL.js 的詳細資訊，請參閱：