问题描述
情况
我有一个使用 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 例如)这是为了确保当您登录时，您也被正确引导回您所在的国家/地区.此外，这使我们能够在需要时将一个国家/地区链接到不同的 AD 实例.
问题
当用户登录应用程序并随后在其会话中注销时，登录过程会正常运行而不会出现问题，并且在尝试再次登录时，他/她会被要求再次登录.这没关系，符合预期.
但是，当用户登录并让他/她的会话过期时，我们会显示一个弹出窗口，询问您是要继续(链接到登录页面)还是退出(链接到注销页面).在这两种情况下，用户都不需要提供他/她的凭据，这不是我们想要的行为(因为这意味着如果有人打开他们的帐户并且发生超时，任何人仍然可以登录到该帐户而无需提供凭据)
观察
- 如果用户在会话超时后点击注销页面，则会调用完全相同的 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 端有 2 种不同的行为.
A) 当会话未过期时，此调用首先调用 https://login.microsoftonline.com/my-azure-ad-guid/oauth2/logout，然后再重定向到我的重定向 uri.
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这对我来说是个问题这个应用程序是什么?为什么在我的身份验证流程中使用它导致我的用户不需要重新进行身份验证?
问题:如何确保用户在每次会话超时后都需要进行身份验证?
更新 04-09-2020:以下信息已弃用.请注意微软的通知:
在预览期间听取客户的意见后，我们实施了 Azure AD 条件访问中的身份验证会话管理功能.您可以使用此新功能通过设置登录频率来配置刷新令牌的生命周期.2020 年 5 月 30 日之后，新租户将无法使用可配置令牌生命周期策略来配置会话和刷新令牌.弃用将在几个月后发生，这意味着我们将停止尊重现有会话并刷新令牌策略.您仍然可以在弃用后配置访问令牌的生命周期.
我相信可以利用用户登录频率".由于浏览器会话的持久性"这一事实，现在设置现在已正确完成.遗憾的是，我无法对此进行测试，因此如果有人可以确认，请在此问题的新答案中描述您是如何成功解决此问题的，我将更改答案并将此消息指向您的答案.
旧信息:
因此，在与 Microsoft 支持团队合作数周后，我们终于有了一个最终的答案和明确的解决方案:
您正在使用登录策略.由于遗留原因，当您调用/authorize 端点以获取登录策略"时，您首先点击 Azure AD B2C 服务，然后立即重新路由到 Azure AD 服务.然后，用户名/密码字段实际上由 Azure AD 服务(而不是 Azure AD B2C)显示.输入有效的用户名/密码后，Azure AD 会出于 SSO 原因在客户端计算机上存储一个 cookie，将客户端重定向回 Azure AD B2C，然后生成一个令牌并将 B2C 令牌返回给应用程序，同时存储它自己的出于 SSO 原因的 cookie.换句话说，Azure AD B2C 联合到 Azure AD 进行登录，Azure AD 和 Azure AD B2C 都有自己的 cookie 来维护 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，用户无需再次输入用户名/密码(这正是您不希望的行为).
若要立即解决此问题，请在调用 Azure AD B2C 的注销终结点后调用 Azure AD 的注销终结点.Azure AD 的注销终结点与 Azure AD B2C 的注销终结点相同，但 URL 中没有策略.对于会话到期，您还需要 限制 Azure AD 的会话超时.
我们正在制定一项不依赖于 Azure AD 的登录策略(目前为私人预览版).我们还在研究修复原始登录策略的行为.
我的问题的解决方案确实是使用规定令牌生命周期的策略来限制 Azure AD 本身的会话超时.这是我设置的策略，即租户上的所有会话一般都过期 15 分钟(这是我们的愿望，如果您只想为特定应用程序设置此策略，请阅读文章)
Connect-AzureADNew-AzureADPolicy -Definition @('{"TokenLifetimePolicy":{"Version":1,"MaxAgeSessionSingleFactor":"0.00:15:00""MaxAgeSessionMultiFactor":"0.00:15:00"}}') -DisplayName "TokenLifetimeDefaultPolicy";-IsOrganizationDefault $true -Type TokenLifetimePolicy"断开连接-AzureAD感谢微软支持.
Situation
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.
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.
Problem
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)
Oservations
- 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.1554as when a user would logout during his/her session. However I see 2 different behaviours on the Azure side on this call.
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) When the session expired this call directly redirects to my redirect uri without passing over the uri in situation A.
There is 1 cookie difference between situation A and B called
x-ms-cpim-sso:myazuread.onmicrosoft.com/b2c_1_mypolicynameit 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.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=StatePropertiesthis 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?
UPDATE 04-09-2020:The information below is deprecated. Please take note of the notice by Microsoft:
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.
OLD INFORMATION:
So after a few weeks of cooperation with the Microsoft Support team we finally have a closing answer and definite solution:
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
Thanks to Microsoft Support.
这篇关于会话超时后 Azure AD B2C 注销的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！