一小时后，身份将从承载令牌中消失 [英] Identity disappears from bearer token after an hour

问题描述

我正在使用带有Web应用程序和Web API的Azure AD来开发多租户解决方案.该Web应用程序使用OpenIdConnect检索承载令牌(在Azure Redis缓存中缓存)，该令牌在Angular中用于从Web api获取JSON.在Web应用程序和Web api(在Azure AD应用程序中设置)之间使用用户模拟.

I am working on a multi-tenant solution with Azure AD with web apps and a web api. The web app uses OpenIdConnect to retrieve a bearer token (which is cached in Azure Redis Cache), which is used in Angular to get JSON from the web api. User impersonation is used between the web app and web api (set up in Azure AD applications).

问题:

这可以正常工作大约一个小时，然后身份突然在网络api一侧消失.如果刷新Web应用程序，我会看到页面被重定向到Microsoft登录页面，但是无需执行任何操作，因为用户只是被重定向回Web应用程序，并且一切正常.据我所知，Web应用程序在失败时使用相同的承载令牌，而在刷新(相同的到期时间)后再次使用时，则使用相同的承载令牌. AuthenticationContext.AcquireTokenSilent在两种情况下均可使用.

This works fine for about an hour, then the Identity suddenly disappears on the web api side. If I refresh the web app, I see that the page is redirected to the Microsoft login page, but no action is required since the user is just redirected back to the web app and everything works again. As far as I can see, the web app uses the same bearer token when it fails and after the refresh (same expire time) when it works again. AuthenticationContext.AcquireTokenSilent works in both scenarios.

我尝试增加许多不同的超时时间，但是没有任何帮助.我还禁用了Web api上除承载令牌身份验证之外的所有身份验证.我不明白为什么该身份消失，以及为什么它有助于刷新客户端.有任何想法吗? :)

I have tried to increase a lot of different timeouts, but nothing has helped. I have also disabled all but bearer token authentication on the web api. I do not understand why the identity disapears and why it helps to refresh the client. Any ideas? :)

其他信息

这是登录或刷新后(在Web api上)大约一个小时后RequestContext.Principal.Identity的显示方式:

This is how the RequestContext.Principal.Identity looks for about an hour after login or a refresh (on the web api):

大约一个小时后，这将导致身份验证失败:

And this is after about an hour, which causes authentication to fail:

我尝试过的一些代码更改:

Some of the code changes I have tried out:

在网络api HttpConfiguration中:

In web api HttpConfiguration:

config.SuppressDefaultHostAuthentication();
        config.Filters.Add(
            new HostAuthenticationFilter(
                new WindowsAzureActiveDirectoryBearerAuthenticationOptions().AuthenticationType));

这将未经身份验证的主体从WindowsPrincipal更改为ClaimsPrincipal，但是一个小时后仍然失败.

This changed the unauthenticated principal from WindowsPrincipal to ClaimsPrincipal, but it still fails after an hour.

WindowsAzureActiveDirectoryBearerAuthenticationOptions BackChannelTimeout set to 5 days. Still fails

在网络应用程序web.config中:

In the web app web.config:

sessionState timeout="525600" for RedisSessionStateProvider. Still fails

在Web应用程序的OWN身份验证过程中，增加了时间跨度并增加了滑动到期时间.仍然失败:

In the web app owin auth process, increased timespan and added sliding expiration. Still fails:

app.SetDefaultSignInAsAuthenticationType(CookieAuthenticationDefaults.AuthenticationType);
        app.UseCookieAuthentication(new CookieAuthenticationOptions
        {
            CookieSecure = CookieSecureOption.Always,
            ExpireTimeSpan = TimeSpan.FromDays(5),
            SlidingExpiration = true,
            CookieHttpOnly = true
        });
        app.UseOpenIdConnectAuthentication(
            new OpenIdConnectAuthenticationOptions
            {
                ClientId = ClientId,
                Authority = Constants.CommonAuthority,
                UseTokenLifetime = false

更新:

充实一些细节:我们有一个混合MVC Angular Web应用程序.许多MVC菜单项，每个菜单项均会导致该菜单项的Angular单页应用程序". MVC用于路由，身份验证和授权.此外，还将检索其他声明，并将其附加到当前的主体服务器端.菜单项是受Authorized和ClaimsPrincipalPermission属性保护的MVC控制器.由于该网页将在Azure中运行，因此我们将默认的sessionProvider更改为Microsoft.Web.Redis.RedisSessionStateProvider.只有MVC服务器端与该Redis会话缓存对话.承载令牌(非刷新令牌)通过授权的受保护的MVC控制器与Angular共享，然后存储在浏览器会话存储中(类似于adal.js对localstorage的使用?)Angular从启用了CORS的API中获取JSON内容在与MVC应用不同的域中. API和MVC应用程序还属于两个不同的Azure AD应用程序.

To flesh out some details: We have a hybrid MVC Angular web application. Many MVC menu items which each lead to an Angular "single page application" for that menu item. MVC is used for routing, authentication and authorization. In addition, additional claims is retrieved and appended to the current principal server side. The menu items are MVC controllers that are protected with the Authorized and ClaimsPrincipalPermission attributes. Since the web page will run in Azure, we changed the default sessionProvider to Microsoft.Web.Redis.RedisSessionStateProvider. Only the MVC server side talks to this redis session cache. The bearer token (not refresh token) is shared with Angular through an Authorized protected MVC controller, which is then stored in the browser session storage (similar to adal.js use of localstorage?) Angular gets JSON content from a CORS enabled API that lives in a separate domain from the MVC app. The API and MVC app also belong to two different Azure AD applications.

推荐答案

您似乎在这里横穿流程.如果要通过JavaScript进行调用，则应在客户端中获取令牌-类似于

you seem to be crossing flows here. If you are making calls from JavaScript, you should obtain the token in the client - something like http://www.cloudidentity.com/blog/2014/10/28/adal-javascript-and-angularjs-deep-dive/. Redirect based authentication flows in which the outcome is a cookie are not well suited for scenarios in which you call API via JavaScript. Furthermore, if I understood correctly you are obtaining a token as a private client and then sharing it out of band (redis cache) with a public client running inside a user agent. That's a no-no from the security perspective.

那是说:如果您真的真的要适应当前的路线，我建议您看一下

That said: if you are really really set in keeping up with your current route, I suggest taking a look at http://www.cloudidentity.com/blog/2014/04/28/use-owin-azure-ad-to-secure-both-mvc-ux-and-web-api-in-the-same-project/ for achieving full separation between your web UX and web API routes.

这篇关于一小时后，身份将从承载令牌中消失的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！