繁体   English   中英

Azure活动目录注销或清除本机应用程序的令牌缓存

[英]Azure active directory Logout or clear token cache for native app

我有一个C#web API REST服务后端,我提供CMS,网页和Angular2应用程序的服务(这是相关的)。 Angular应用程序需要通过后端发送用户名和密码(原始凭据)进行身份验证,后端使用这些来请求访问Azure Active Directory(使用UserCredentials ),并将access_token发送回Angular应用程序,以用于授权请求( Authorization: Bearer )。 这是我正在验证的方式:

UserCredential uc = new UserPasswordCredential(user, password);
AuthenticationContext authContext = new AuthenticationContext(Constants.authority, false);
AuthenticationResult result = authContext.AcquireTokenAsync(Constants.audience, Constants.clientIdNative, uc).Result;

问题是它为该令牌生成一小时缓存,如果用户注销并再次使用用户或用户+错误密码再次进入,则身份验证只会查找该用户的缓存并忽略或不验证密码。 在一小时的窗口中,任何人都可以使用用户名进入。

我在这里和许多其他网站上找到了注销或清除令牌的方法,但这些不适用于我的后端,因为它是无状态的。 我不管理这些之间的会话或HTTP上下文。 如果有人可以指导解决这个问题,我正在使用Microsoft.IdentityModel.Clients.ActiveDirectory 3.13.1.846版的最后一个程序集,我知道方法AcquireTokenByAuthorizationCodeAsync不会查找缓存但是没有用于原始凭据的实现。

谢谢你们,希望你能帮助我。

你是以下策略强烈建议反对 对于您的应用程序来说,收集用户名和密码通常是不好的做法。 此流( 资源所有者密码凭据(ROPC)授权流)仅适用于其他机制不可用的情况。 从OAuth 2.0规范(重点补充):

1.3.3。 资源所有者密码凭据

资源所有者密码凭证(即,用户名和密码)可以直接用作授权授权以获得访问令牌。 只有在资源所有者和客户端之间存在高度信任时(例如,客户端是设备操作系统或高权限应用程序的一部分), 以及其他授权授权类型不可用时,才应使用凭证(例如授权码)

即使此授权类型要求直接客户端访问资源所有者凭据,资源所有者凭据也会用于单个请求并交换访问令牌。 通过使用长期访问令牌或刷新令牌交换凭证,此授权类型可以消除客户端存储资源所有者凭据以供将来使用的需要。

对Azure AD使用此流时,您会发现此流通常会失败,因为有时需要用户提供的不仅仅是用户名和密码。 一些不起作用的例子:

  • 用户需要同意应用程序请求的权限
  • 用户密码已过期,需要更改
  • 用户的凭据被怀疑被盗用
  • 用户的登录在其他方面被认为是可疑的 (更有可能在您的方案中,因为登录似乎来自Web服务器,可能不在用户所在的位置)
  • 用户启用了多因素身份验证
  • 用户是联合域名的一部分(权威身份提供者不是Azure AD)

基本上,通过使用此方法,您绕过了OAuth 2.0和Azure AD提供的大多数安全性改进,并且您通过使用用户名/密码流以不是这样的方式使自己,应用程序和用户面临风险打算使用。

此外,虽然Azure AD 服务当前支持ROPC流,但您会发现在某些情况下实际上正在从库中删除对此流的支持(例如,问题#320从iOS / Android / WinRT中删除非交互式身份验证和问题#462 PCL UserCredential不再支持密码 )。

回答你的具体问题

(悬停以查看在您的情况下您不应该做什么,但回答有关令牌缓存的问题。)

跳过令牌缓存的一种方法是简单地使用带有TokenCache值的构造函数签名并传入一个空的TokenCache值:

  AuthenticationContext authContext =\n     new AuthenticationContext(Constants.authority,false,null); 

一种更好(但仍然非常糟糕)的方法

(真的,不要这样做,你也可以跳到下一节......)

如果您发现自己的本机客户端应用程序绝对必须使用用户名/密码流,并且您接受风险并愿意与它们一起使用以及所有其他缺点,那么您的Angular应用程序应该向Azure发出令牌请求直接AD, 而不是通过您的API后端。 然后,可以使用收到的访问令牌对您的API(或Azure AD保护的其他API)进行经过身份验证的请求,具体取决于您在令牌请求中指定的resource

正确的方法

正确的方法是让您的本机客户端应用程序使用任何支持的流程,包括将用户(通过Web浏览器或Web视图)发送到Azure AD进行身份验证。 这可确保正确处理上述所有方案中的用户体验(同意提示,更改密码提示,多因素身份验证提示等)。 它还允许您使用令牌缓存(改善整体体验,因为您不会为每次调用后端添加令牌请求)。

用户通过身份验证后,您的应用将拥有访问令牌,刷新令牌和ID令牌。 您可以直接在应用程序后端使用这些令牌。 如果您的应用程序的后端需要在用户的上下文中调用其他API,则可以通过将其从本机客户端应用程序获取的访问令牌交换为另一个资源(代表该用户)来执行此操作。访问令牌最初被授予(事实上,有一个样本正是这样做的: active-directory-dotnet-webapi-onbehalfof )。

对于Angular2应用程序,我建议看一下ADAL for JavaScript库,结合一些似乎添加了对Angular2的支持的包装库(例如angular2-adal )。

暂无
暂无

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM