更新 1 2021-10-24
- 我們使用兩種不同的“經典”登錄/注冊策略，甚至早于 MSAL 0.15。我們不使用自定義策略。我相信我們可以使用應用程式的清單匯出它們，這會有用嗎？如果我在這里發帖，我希望編輯可識別資訊，但不確定這是否會使它們無用......
- 關于 SSO，我認為 @JasSuri-MSFT 所說的是因為宣告集相同/相似，策略 ID 本身被忽略（出于 SSO 目的）？這是否記錄在某處，以便我們可以了解宣告集需要有多大不同？
- 鑒于這種 SSO 行為，有沒有辦法讓策略 ID 本身用于識別 SSO？這就是我為 MSAL 2.x 發布這篇初始帖子的原因，因為在配置中我可能缺少一些東西來恢復以前的行為。
初始職位
我們最近將 SPA 從 MSAL 0.x 升級到 2.x，升級為在 B2C 中使用 OAuth 2.0 授權代碼流和 PKCE。這是完整的并且適用于 2.16.1，我們嘗試升級到 2.18.0 沒有成功解決以下“問題”。
作為升級作業的一部分，我們注意到如果租戶存在現有的身份驗證結果，登錄重定向將被繞過，我們立即處理身份驗證程序（AKA acquireTokenSilent()），這很好，因為如果我們剛剛登錄并前往不同的SPA 的選項卡，我們立即登錄該選項卡。
但是，我們在同一租戶中使用具有不同 B2C 策略的不同 SPA，并且我們意外地從一個 SPA 策略中獲得了針對不同 SPA 策略（在同一租戶中）的身份驗證結果。我們的應用程式捕獲了這個并報告了一個錯誤（因為訪問令牌中的宣告不兼容），但我們正在嘗試了解我們可以做些什么來防止這種混亂的情況。
作為背景，我會在這里犯錯并說我們使用的是 MSAL 0.1.5 (!!)。在此版本下，每個 SPA 分別進行身份驗證，每個 SPA 可以同時登錄到同一個租戶，互不干擾（附屬于不同的域）。
MSAL 2.x 中的問題不再是這種情況，而且似乎身份驗證（特別是宣告）在 B2C 策略之間“泄漏”。我已經檢查了msal.PublicClientApplication()其他設定，但什么也沒看到。我確實看到了一個forceRefresh標志，acquireTokenSilent()但這表明它用于網路令牌檢查，打開它對獲取跨策略身份驗證結果沒有任何影響。
我們注意到的是，回應中包含的權限（通過 傳遞handleRedirectPromise()）是第二個 SPA 的正確策略 ID。此外，當我們使用acquireTokenSilent()提供給我們的 Web 服務器的訪問令牌時，它具有tfp第二個 SPA的正確策略 ID（在宣告中），但來自該訪問令牌的宣告適用于第一個 SPA 的策略和經過身份驗證的用戶。請注意，我們專門驗證了tvps.AuthenticationType自tfp更新以來正確的第二個 SPA ！
這是復制序列（節略形式）：
- 在選項卡 1 (*) 上打開 SPA 1 登錄頁面
- 重定向到 B2C 頁面進行身份驗證
- 重定向回 SPA 1，在那里
acquireTokenSilent()為 SPA 1完成身份驗證 - Web 服務器驗證 SPA 1 的 SPA 1 訪問令牌宣告
- 在選項卡 2 (*) 上打開 SPA 2 登錄頁面
- Redirect back to SPA 2 where authentication is completed by
acquireTokenSilent()for SPA 2 - Web server rejects SPA 1 access token claims for SPA 2 since the claims values are incompatible with the API call, but the
tfpclaim matches the 2nd SPA's policy id
(*) It appears that when the msal.PublicClientApplication()/loginRedirect() is performed, if there is a recent login the B2C login page redirect is bypassed and we immediately go into the handleRedirectPromise(). It seems this is where the authentication result from the old SPA 1 login gets passed back. Note that the response's authority IS correct for SPA 2.
Here is the format of the authority field in the msal.PublicClientApplication() config:
authority: `https://<ourtenant>.b2clogin.com/tfp/<ourtenant>.onmicrosoft.com/B2C_1_${policyId}`
where:
policyId has the form of 'sign-up-in-spa' or 'sign-up-in-spa-phn'
So:
- Are we reading this situation correctly, that different B2C policies in the same tenant can reuse an existing authentication result?
- Is it possible to make MSAL (et al) enforce the B2C policy such it would only return existing the authentication result for the matching policy? That is, don't cross contaminate claims from different policies.
uj5u.com熱心網友回復：
答案是此行為是在會話的 B2C 用戶流中定義的。看起來我們非常古老的 MSAL 0.15 使用完全忽略了這個設定，可能 (?) 因為我們使用的是隱式流。我們猜測使用 PKCE 的更安全的授權代碼啟用了強制執行。
這是微軟關于 B2C 會話行為的文章：
感謝 @JasSuri-MSFT，因為您的評論讓我對會話管理和 SSO 感到興奮。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/338728.html
標籤：authentication single-page-application azure-ad-b2c msal msal.js