会话超时后，Azure AD B2C注销 [英] Azure AD B2C logout after session timeout

问题描述

情况

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

I have a web application that is using Azure AD B2C as its authentication. We're using OWIN OpenIdConnect to handle this process. The session timeouts are set to 15 minutes (sessionState in web.config and on our AzureADB2C signin policy) and we have SSO enabled in the policy on the policy level. The session is set to be rolling. The OWIN CookieAuthentication is also using a 15m sliding expiry.

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

The web application is split into multiple parts (virtual folders) but are all sharing the same Azure AD B2C instance. However each has its own application registration in the AD. (These are basically the countries so we have www.site.com/nl and www.site.com/de for example) This to ensure that when you login you are also directed properly back to the country you were operating in. Additionally this enables us to link a country to a different AD instance should this be required.

问题

当用户登录到应用程序，然后随后在其会话中注销时，登录过程将正常运行而不会出现问题，并且在尝试再次登录时，要求他/她再次登录.没关系，而且符合预期.

When a user logs into the application and then subsequently logs out within his/her session the login process runs properly without issue and upon trying to login again he/she is requested to login again. This is OK and as expected.

但是，当用户登录并让他/她的会话到期时，我们会显示一个弹出窗口，询问您是要继续(链接到登录页面)还是退出(链接到注销页面).两种情况下，用户都不需要提供他/她的凭据，这也不是我们所希望的行为(这意味着如果有人将其帐户保持打开状态并且发生超时，则任何人都仍可以登录到该帐户而无需提供凭据)

However when a user logs in and lets his/her session expire we display a popup that asks whether you'd like to continue (links to the login page) or quit (links to the logout page). Both cases the user does not need to provide his/her credentials and this is not our desired behaviour (as this would mean if someone leaves their account open and timeout occurs anyone can still login to this account without needing to present credentials)

预订

1. 如果用户在会话超时后访问注销页面，则该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，与用户在会话期间注销时的URL完全相同.但是，在此调用中，我在Azure端看到了两种不同的行为.

1. If a user hits up the logout page after session timeout the exact same url is called 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 as when a user would logout during his/her session. However I see 2 different behaviours on the Azure side on this call.

A)当会话未到期时，此呼叫将先呼叫https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout，然后再重定向到我的重定向uri.

A) When the session did not expire this call first calls into https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout before redirecting to my redirect uri.

B)会话期满后，此调用将直接重定向到我的重定向uri，而不会在情况A下通过uri.

B) When the session expired this call directly redirects to my redirect uri without passing over the uri in situation A.

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

1. There is 1 cookie difference between situation A and B called x-ms-cpim-sso:myazuread.onmicrosoft.com/b2c_1_mypolicyname it only exists in situation A which leads me to believe that this causes the different behaviour. However this is a Microsoft cookie on the login.microsoftonline.com domain so I have no control or influence over this.

在会话超时后初始化登录时，我看到呼叫通过包含与我的任何应用程序都不匹配的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这为我提出了一个问题，该应用程序是什么，为什么?在我的身份验证流程中使用过，导致我的用户不需要重新身份验证?

When the login is initialized after session timeout I see calls pass by containing a clientid that does not match with any of my applications: 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 this begs the question for me what is this application and why is it being used in my auth flow causing my user not needing to re-authenticate?

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

Question: How do I ensure that users will need to authenticate after each session timeout?

推荐答案

更新04-09-2020: 以下信息已弃用.请注意Microsoft的通知:

UPDATE 04-09-2020: The information below is deprecated. Please take note of the notice by Microsoft:

在预览期间听取客户的意见后，我们实施了

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.

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

I believe that it may be possible to utilize the "User Signin Frequency" setting now thanks to the fact the "Persistance for Browser Sessions" is now properly done. Sadly I cannot test this so if anyone can confirm please describe in a new answer to this question how you've successfully managed this issue and I'll change the answer and direct this message to your answer.

旧信息:

因此，在与Microsoft支持团队合作几周之后，我们终于有了一个明确的答案和明确的解决方案:

So after a few weeks of cooperation with the Microsoft Support team we finally have a closing answer and definite solution:

您正在使用登录策略.由于遗留原因，当您为登录策略"调用/authorize终结点时，首先单击Azure AD B2C服务，然后立即将其重新路由到Azure AD服务.然后，Azure AD服务(而不是Azure AD B2C)实际显示用户名/密码的字段.输入有效的用户名/密码后，Azure AD出于SSO原因将cookie存储在客户端计算机上，将客户端重定向回Azure AD B2C，Azure AD B2C然后铸造一个令牌并将B2C令牌返回给应用程序，并存储自己的令牌出于SSO原因的Cookie.换句话说，Azure AD B2C联合到Azure AD进行登录，Azure AD和Azure AD B2C都有自己的cookie来维护SSO.

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.

现在，当您调用注销到Azure AD B2C或Azure AD B2C的会话期满时，Azure AD B2C会执行其操作来关闭会话，即删除cookie.但是，它不会删除Azure AD cookie.这意味着当您再次登录时，Azure AD B2C会识别出您尚未登录，并调用Azure AD.由于Azure AD植入了cookie或Azure AD的会话没有过期，因此该用户是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).

要暂时解决此问题，请在调用Azure AD B2C的注销终结点后再调用Azure AD的注销终结点. Azure AD的注销终结点与Azure AD B2C的注销终结点相同，但URL中没有策略.对于会话到期，您还需要限制Azure AD的会话超时.

我们正在研究不依赖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分钟(这是我们的愿望，如果您仅想针对特定应用程序设置此策略，请阅读本文)

The solution to my question was indeed to limit the session timeout of Azure AD itself using policies that dictate token lifetimes. Here's the policy I set to expire in general all session on the tenant to 15 minutes (which was our desire, read the article if you want to set this policy only for specific applications etc)

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支持.

Thanks to Microsoft Support.

这篇关于会话超时后，Azure AD B2C注销的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！