session 超时后 Azure AD B2C 注销

Question

情况

我有一个使用 Azure AD B2C 作为其身份验证的 Web 应用程序。我们使用 OWIN OpenIdConnect 来处理此过程。 session 超时设置为 15 分钟(web.config 中的 sessionState 和我们的 AzureADB2C 登录策略)，并且我们在策略级别的策略中启用了 SSO。 session 设置为滚动形式。 OWIN CookieAuthentication 也使用 15m 滑动到期时间。

Web 应用程序分为多个部分(虚拟文件夹)，但都共享同一个 Azure AD B2C 实例。然而，每个在 AD 中都有自己的应用程序注册。 (这些基本上是国家/地区，因此我们有 www.site.com/nl 和 www.site.com/de)这可以确保您登录时也能正确返回您所在的国家/地区。此外，如果需要，我们可以将一个国家/地区链接到不同的 AD 实例。

问题

当用户登录到应用程序，然后在他/她的 session 中注销时，登录过程会正常运行，不会出现问题，并且在尝试再次登录时，会要求他/她再次登录。这没问题并且符合预期。

但是，当用户登录并让他/她的 session 过期时，我们会显示一个弹出窗口，询问您是否要继续(指向登录页面的链接)或退出(指向注销页面的链接)。这两种情况下，用户都不需要提供他/她的凭据，这不是我们想要的行为(因为这意味着如果有人保持其帐户处于打开状态并且发生超时，任何人仍然可以登录该帐户而无需提供凭据)

观察

1. 如果用户在 session 超时后点击注销页面，则会调用完全相同的 URL https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/v2.0/logout?p=b2c_1_mypolicyname&post_logout_redirect_uri =https%3a%2f%2fwww.site.com%2fbe&x-client-SKU=ID_NET&x-client-ver=1.0.40306.1554 当用户在 session 期间注销时。不过，我在这次调用中看到 Azure 端有 2 种不同的行为。

A) 当 session 未过期时，此调用首先调用 https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout，然后重定向到我的重定向 URI .

B) 当 session 过期时，此调用直接重定向到我的重定向 uri，而不传递情况 A 中的 uri。

情况 A 和 B 之间有 1 个名为 x-ms-cpim-sso:myazuread.onmicrosoft.com/b2c_1_mypolicyname 的 cookie 差异，它仅存在于情况 A 中，这让我相信这会导致不同的行为。然而，这是 login.microsoftonline.com 域上的 Microsoft cookie，因此我对此无法控制或影响。

当 session 超时后初始化登录时，我看到调用包含与我的任何应用程序都不匹配的 clientid:https://login.microsoftonline.com/myazuread.onmicrosoft.com/oauth2/authorize?client_id=bb2a2e3a-c5e7-4f0a-88e0-8e01fd3fc1f4&redirect_uri=https%3a%2f%2flogin.microsoftonline.com%2fte%2fmyazuread.onmicrosoft.com%2foauth2%2fauthresp&response_type=id_token&scope=email+openid&res ponse_mode=查询&nonce=nonce&nux =1&nca=1&domain_hint=myazuread.onmicrosoft.com&mkt=en-US&lc=1033&state=StateProperties 这给我带来了一个问题:这个应用程序是什么以及为什么它在我的身份验证流程中使用，导致我的用户不需要重新 -进行身份验证吗？

问题:如何确保用户在每次 session 超时后都需要进行身份验证？

Answer 1

2020 年 9 月 4 日更新:以下信息已被弃用。请注意微软的通知:

After hearing from customers during the preview, we've implemented authentication session management capabilities in Azure AD Conditional Access. You can use this new feature to configure refresh token lifetimes by setting sign in frequency. After May 30, 2020 no new tenant will be able to use Configurable Token Lifetime policy to configure session and refresh tokens. The deprecation will happen within several months after that, which means that we will stop honoring existing session and refresh tokens polices. You can still configure access token lifetimes after the deprecation.

我相信现在可以利用“用户登录频率”设置，因为“浏览器 session 持久性”现在已正确完成。遗憾的是，我无法对此进行测试，因此如果有人可以确认，请在该问题的新答案中描述您如何成功解决此问题，我将更改答案并将此消息定向到您的答案。

旧信息:

经过与 Microsoft 支持团队几周的合作，我们终于得到了最终答案和明确的解决方案:

You are using a sign in policy. For legacy reasons, when you make a call to the /authorize endpoint for a “Sign in policy”, you first hit the Azure AD B2C service, and then immediately get rerouted to the Azure AD service. The field for username/password is then actually displayed by the Azure AD service (and not by Azure AD B2C). Once you enter a valid username/password, Azure AD stores a cookie on the client machine for SSO reasons, redirects the client back to Azure AD B2C, which then mints a token and returns a B2C token to the application, along with storing its own cookies for SSO reasons. In other words, Azure AD B2C federates to Azure AD for the sign in, and both Azure AD and Azure AD B2C have cookies of their own to maintain SSO.

Now when you call logout to Azure AD B2C or when Azure AD B2C’s session expires, Azure AD B2C does its thing to close the session, which is to delete the cookies. However, it does not delete the Azure AD cookies. Which means that when you sign in again, Azure AD B2C recognizes that you’re not signed in, and calls Azure AD. Because Azure AD has cookies planted or Azure AD’s session is not expired, it SSO’s the user and the user does not need to enter the username/password again (which is the exact behavior you do not want).

To work around this for right now, please also call the logout endpoint for Azure AD after you call the logout endpoint for Azure AD B2C. The logout endpoint for Azure AD is the same as the logout endpoint for Azure AD B2C, but without the policy in the URL. For session expiry, you will need to also limit the session timeout for Azure AD.

We are working on a sign-in policy (currently in private preview) that do not take a dependency on Azure AD. We are also looking into fixing the behavior for the original Sign in policies.

我的问题的解决方案确实是使用规定 token 生命周期的策略来限制 Azure AD 本身的 session 超时。这是我设置的策略，一般来说，租户上的所有 session 都会过期 15 分钟(这是我们的愿望，如果您只想为特定应用程序等设置此策略，请阅读本文)

Connect-AzureAD
New-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1, "MaxAgeSessionSingleFactor":"0.00:15:00","MaxAgeSessionMultiFactor":"0.00:15:00"}}') -DisplayName "TokenLifetimeDefaultPolicy" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"
Disconnect-AzureAD

感谢 Microsoft 支持。