会话超时后 Azure AD B2C 注销
Azure AD B2C logout after session timeout
情况
我有一个使用 Azure AD B2C 作为身份验证的 Web 应用程序。我们正在使用 OWIN OpenIdConnect 来处理这个过程。会话超时设置为 15 分钟（web.config 中的 sessionState 和我们的 AzureADB2C 登录策略）并且我们在策略级别的策略中启用了 SSO。会话设置为滚动。 OWIN CookieAuthentication 也使用 15m 滑动到期。
Web 应用程序分为多个部分（虚拟文件夹），但都共享同一个 Azure AD B2C 实例。但是，每个在 AD 中都有自己的应用程序注册。 （这些基本上是国家，所以我们有 www.site.com/nl 和 www.site.com/de 例如）这是为了确保当你登录时你也被正确地引导回您运营所在的国家/地区。此外，如果需要，这使我们能够 link 一个国家/地区到不同的 AD 实例。
问题
当用户登录到应用程序然后随后在 his/her 会话中注销时，登录过程正常运行，没有问题，并且在尝试再次登录时 he/she 被请求再次登录。这没问题，符合预期。
然而，当用户登录并让 his/her 会话过期时，我们会显示一个弹出窗口，询问您是要继续（links 到登录页面）还是退出（links 到注销页面）。在这两种情况下，用户都不需要提供 his/her 凭据，这不是我们想要的行为（因为这意味着如果有人打开他们的帐户并且发生超时，任何人仍然可以登录该帐户而无需提供凭据）
观察
- 如果用户在会话超时后点击注销页面，与用户在 his/her 会话期间注销时调用的 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。但是，我在这个调用中看到 Azure 端有两种不同的行为。
A) 当会话未过期时，此调用在重定向到我的重定向 uri 之前首先调用 https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout。
B) 当会话过期时，此调用直接重定向到我的重定向 uri，而不传递情况 A 中的 uri。
情况 A 和 B 之间存在 1 个 cookie 差异，称为 x-ms-cpim-sso:myazuread.onmicrosoft.com/b2c_1_mypolicyname 它仅存在于情况 A 中，这让我相信这会导致不同的行为。但是，这是 login.microsoftonline.com 域上的 Microsoft cookie，因此我无法控制或影响它。
当登录在会话超时后初始化时，我看到包含与我的任何应用程序都不匹配的 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&response_mode=query&nonce=nonce&nux=1&nca=1&domain_hint=myazuread.onmicrosoft.com&mkt=en-US&lc=1033&state=StateProperties 这引出了我的问题这是什么应用程序以及为什么在我的身份验证流程中使用它导致我的用户不需要重新进行身份验证？
问题:
如何确保用户在每次会话超时后都需要进行身份验证？
2020 年 4 月 9 日更新：
以下信息已弃用。请注意微软的通知：
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.
我相信现在可以使用“用户登录频率”设置，这要归功于“浏览器会话的持久性”现在已正确完成。遗憾的是我无法对此进行测试，所以如果有人可以确认，请在这个问题的新答案中描述你是如何成功解决这个问题的，我会更改答案并将此消息转发给你的答案。
旧信息：
所以经过与微软支持团队几周的合作，我们终于有了一个结束的答案和明确的解决方案：
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.
我的问题的解决方案确实是使用指示令牌生命周期的策略来限制 Azure AD 本身的会话超时。这是我设置的策略，一般情况下租户的所有会话都会过期 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 支持。
目的是在闲置 15 分钟后设置闲置用户的会话超时。
我们在本地 IIS 上有两个 Web 应用程序 运行（它 should/must 在 ms azure 云中表现相同）
No.1 MVC web 应用程序（这里我们需要非活动用户的超时在 15 分钟后发生）
No.2 MVC 休息 api
我们必须做的是创建一个新策略并分配给一个服务主体对象。
请使用下面提到的步骤 1-6。
1.Download 最新的 Azure AD PowerShell 模块 Public 预览版。
2.Run 连接命令登录到您的 Azure AD 管理员帐户。 运行 每次启动新会话时执行此命令。
连接-AzureAD -确认
- 创建新策略
New-AzureADPolicy -定义@('{"TokenLifetimePolicy":{"Version":1, "AccessTokenLifetime":"00:15:00","MaxInactiveTime":"00:15:00 ","MaxAgeSingleFactor":"01:00:00", "MaxAgeSessionSingleFactor":"01:00:00"}}') -DisplayName "KBTokenLifetimePolicy" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"
4.Find 所需的 Azure AD B2C - 应用程序（服务主体对象）ObjectId
获取 AzureADServicePrincipal -Filter "DisplayName eq 'MultitenentPortal'"
ObjectId AppId 显示名称
5.List 策略并获取 KBTokenLifetimePolicy 策略的 ObjectId
获取 AzureADPolicy
ID DisplayName 类型 IsOrganizationDefault
–------------------------------------
6.To 将策略添加到 web Azure AD B2C - 应用程序（服务主体对象）：
添加 AzureADServicePrincipalPolicy -Id -RefObjectId
结果：到目前为止应用程序没有超时。在 15 分钟的非活动期后，它仍然继续在页面之间导航并显示来自 api.
的数据
情况
我有一个使用 Azure AD B2C 作为身份验证的 Web 应用程序。我们正在使用 OWIN OpenIdConnect 来处理这个过程。会话超时设置为 15 分钟（web.config 中的 sessionState 和我们的 AzureADB2C 登录策略）并且我们在策略级别的策略中启用了 SSO。会话设置为滚动。 OWIN CookieAuthentication 也使用 15m 滑动到期。
Web 应用程序分为多个部分（虚拟文件夹），但都共享同一个 Azure AD B2C 实例。但是，每个在 AD 中都有自己的应用程序注册。 （这些基本上是国家，所以我们有 www.site.com/nl 和 www.site.com/de 例如）这是为了确保当你登录时你也被正确地引导回您运营所在的国家/地区。此外，如果需要，这使我们能够 link 一个国家/地区到不同的 AD 实例。
问题
当用户登录到应用程序然后随后在 his/her 会话中注销时，登录过程正常运行，没有问题，并且在尝试再次登录时 he/she 被请求再次登录。这没问题，符合预期。
然而，当用户登录并让 his/her 会话过期时，我们会显示一个弹出窗口，询问您是要继续（links 到登录页面）还是退出（links 到注销页面）。在这两种情况下，用户都不需要提供 his/her 凭据，这不是我们想要的行为（因为这意味着如果有人打开他们的帐户并且发生超时，任何人仍然可以登录该帐户而无需提供凭据）
观察
- 如果用户在会话超时后点击注销页面，与用户在 his/her 会话期间注销时调用的 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。但是，我在这个调用中看到 Azure 端有两种不同的行为。
A) 当会话未过期时，此调用在重定向到我的重定向 uri 之前首先调用 https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout。
B) 当会话过期时，此调用直接重定向到我的重定向 uri，而不传递情况 A 中的 uri。
情况 A 和 B 之间存在 1 个 cookie 差异，称为
x-ms-cpim-sso:myazuread.onmicrosoft.com/b2c_1_mypolicyname它仅存在于情况 A 中，这让我相信这会导致不同的行为。但是，这是 login.microsoftonline.com 域上的 Microsoft cookie，因此我无法控制或影响它。当登录在会话超时后初始化时，我看到包含与我的任何应用程序都不匹配的 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&response_mode=query&nonce=nonce&nux=1&nca=1&domain_hint=myazuread.onmicrosoft.com&mkt=en-US&lc=1033&state=StateProperties这引出了我的问题这是什么应用程序以及为什么在我的身份验证流程中使用它导致我的用户不需要重新进行身份验证？
问题: 如何确保用户在每次会话超时后都需要进行身份验证？
2020 年 4 月 9 日更新： 以下信息已弃用。请注意微软的通知：
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.
我相信现在可以使用“用户登录频率”设置，这要归功于“浏览器会话的持久性”现在已正确完成。遗憾的是我无法对此进行测试，所以如果有人可以确认，请在这个问题的新答案中描述你是如何成功解决这个问题的，我会更改答案并将此消息转发给你的答案。
旧信息：
所以经过与微软支持团队几周的合作，我们终于有了一个结束的答案和明确的解决方案：
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.
我的问题的解决方案确实是使用指示令牌生命周期的策略来限制 Azure AD 本身的会话超时。这是我设置的策略，一般情况下租户的所有会话都会过期 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 支持。
目的是在闲置 15 分钟后设置闲置用户的会话超时。 我们在本地 IIS 上有两个 Web 应用程序 运行（它 should/must 在 ms azure 云中表现相同）
No.1 MVC web 应用程序（这里我们需要非活动用户的超时在 15 分钟后发生）
No.2 MVC 休息 api
我们必须做的是创建一个新策略并分配给一个服务主体对象。
请使用下面提到的步骤 1-6。
1.Download 最新的 Azure AD PowerShell 模块 Public 预览版。
2.Run 连接命令登录到您的 Azure AD 管理员帐户。 运行 每次启动新会话时执行此命令。 连接-AzureAD -确认
- 创建新策略 New-AzureADPolicy -定义@('{"TokenLifetimePolicy":{"Version":1, "AccessTokenLifetime":"00:15:00","MaxInactiveTime":"00:15:00 ","MaxAgeSingleFactor":"01:00:00", "MaxAgeSessionSingleFactor":"01:00:00"}}') -DisplayName "KBTokenLifetimePolicy" -IsOrganizationDefault $true -Type "TokenLifetimePolicy"
4.Find 所需的 Azure AD B2C - 应用程序（服务主体对象）ObjectId 获取 AzureADServicePrincipal -Filter "DisplayName eq 'MultitenentPortal'" ObjectId AppId 显示名称
5.List 策略并获取 KBTokenLifetimePolicy 策略的 ObjectId 获取 AzureADPolicy ID DisplayName 类型 IsOrganizationDefault –------------------------------------
6.To 将策略添加到 web Azure AD B2C - 应用程序（服务主体对象）： 添加 AzureADServicePrincipalPolicy -Id -RefObjectId
结果：到目前为止应用程序没有超时。在 15 分钟的非活动期后，它仍然继续在页面之间导航并显示来自 api.
的数据