Question

场合

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

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

问题

当用户登录应用程序然后随后在他/她的会话中注销时，登录过程正常运行而没有问题，并且在尝试再次登录时，他/她被要求再次登录。这没关系，正如预期的那样。

然而，当用户登录并让他/她的会话过期时，我们会显示一个弹出窗口，询问您是否要继续（链接到登录页面）或退出（链接到登出页面）。在这两种情况下，用户都不需要提供他/她的凭据，这不是我们想要的行为（因为这意味着如果有人离开他们的帐户并发生超时，任何人仍然可以登录此帐户而无需提供凭据）

Oservations

如果用户在会话超时后点击注销页面，那么与用户在他/她的会话期间注销时完全相同的网址称为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）当会话未到期时，此呼叫首先调用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这对我来说问题是什么是这个应用程序，为什么是它在我的auth流程中使用，导致我的用户不需要重新进行身份验证？

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

Answer 1

因此，在与Microsoft支持团队合作几周后，我们终于得到了一个结束答案和明确的解决方案：

您正在使用登录政策。由于遗留原因，当您调用/授权端点以获取“登录策略”时，首先点击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。

现在，当您调用logout到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中没有策略。对于会话到期，您还需要limit the session timeout for Azure AD。

我们正在制定一个不依赖Azure AD的登录策略（当前处于私有预览状态）。我们还在研究修复原始登录策略的行为。

我的问题的解决方案确实是使用规定令牌生存期的策略来限制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支持。

Answer 2

目的是在15分钟不活动之后设置一个不活动的用户会话超时。我们在本地IIS上运行了两个Web应用程序（它应该/必须在ms azure云中表现相同）

第1个MVC Web应用程序（此处我们需要15分钟后发生不活动的用户超时）

第2个MVC Rest API

我们要做的是创建一个新策略并将其分配给Service主体对象。

请使用下面提到的步骤1-6。

1。下载最新的Azure AD PowerShell模块公共预览版本。

2。运行“连接”命令以登录到您的Azure AD管理员帐户。每次启动新会话时，请运行此命令。 Connect-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-键入” TokenLifetimePolicy“

4。找到所需的Azure AD B2C-应用程序（服务主体对象）ObjectId Get-AzureADServicePrincipal-筛选器“ DisplayName eq'MultitenentPortal'” ObjectId AppId DisplayName

5。列出策略并获取KBTokenLifetimePolicy策略的ObjectId Get-AzureADPolicy ID DisplayName类型IsOrganizationDefault – ----------- ---- ---------------------

6。向Web Azure AD B2C添加策略-Applications（服务主体对象）： Add-AzureADServicePrincipalPolicy -Id -RefObjectId

结果：到目前为止，应用程序尚未超时。闲置15分钟后，它仍会继续在页面之间导航并显示api中的数据。

会话超时后，Azure AD B2C注销

2 个答案: