c# - Azure Active Directory注销或清除 native 应用程序的 token 缓存

Question

我有一个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;

事实是，它会为该令牌生成一个一小时的缓存，并且如果用户注销并仅使用该用户或用户+错误的密码再次输入，则Authentication只会查找该用户的缓存，而忽略或不验证密码。在一个小时的窗口中，任何人都可以使用用户名进入。

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

谢谢大家，希望您能帮助我。

Answer 1

强烈建议您遵循以下策略。通常，对于您的应用程序来说，完全不收集用户名和密码是一种不好的做法。此流（Resource Owner Password Credentials (ROPC) Grant流）仅用于其他机制不可用的情况。根据OAuth 2.0规范（添加了重点）：


  1.3.3。资源所有者密码凭证
  
  资源所有者的密码凭据（即用户名和密码）
    可以直接用作授权授予以获得访问权限
    令牌。凭证仅在存在高级别时才使用
    资源所有者和客户之间的信任度（例如，
    客户端是设备操作系统的一部分，或者是特权很高的客户端
    申请），以及其他授权类型不是
    可用（例如授权码）。
  
  即使此授予类型要求客户直接访问
    资源所有者凭证，使用资源所有者凭证
    单个请求，并交换访问令牌。这个
    授予类型可以消除客户端存储
    通过交换资源所有者凭证以供将来使用
    具有长期访问令牌或刷新令牌的凭据。


对Azure AD使用此流时，您会发现此流通常会失败，因为有时要求用户提供的不仅仅是用户名和密码。一些无法正常工作的示例：


用户需要同意应用程序所请求的权限
用户密码已过期，需要更改
用户的凭证are suspected of being compromised
用户的登录is otherwise considered suspicious（在您的情况下，更可能是因为登录似乎来自Web服务器，而该Web服务器可能不在用户所在的位置）
用户已启用多因素身份验证
用户是联合域名的一部分（其中权威身份提供者不是Azure AD）


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

此外，尽管Azure AD服务当前确实支持ROPC流程，但您会发现在某些情况下实际上已从库中删除了对该流程的支持（例如，问题＃320从iOS / Android / WinRT中删除非交互式身份验证，并且< aa>）。

回答您的特定问题

（悬停以查看您不应该执行的操作，而是回答有关令牌缓存的问题。）


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

 AuthenticationContext authContext =
    新的AuthenticationContext（Constants.authority，false，null）;


更好（但仍然很糟糕）的方法

（真的，不要这样做，您最好跳到下一节...）


   如果您发现自己的本地客户端应用程序绝对必须使用用户名/密码流，并且您接受了风险并愿意与他们共处，并承担了所有其他缺点，那么您的Angular应用程序应该对Azure实施Issue #462 PCL UserCredential no longer supports password直接广告，而不通过您的API后端。然后，可以使用收到的访问令牌对您的API（或由Azure AD保护的其他API，取决于您在令牌请求中指定为resource的对象）发出经过身份验证的请求。


正确的方法

正确的方法是使您的本机客户端应用程序利用任何受支持的流程，这些流程涉及将用户（通过Web浏览器或Web视图）发送到Azure AD进行身份验证。这样可以确保正确处理以上所有情况下的用户体验（同意提示，更改密码提示，多因素身份验证提示等）。它还将允许您利用令牌缓存（改善整体体验，因为您没有为每次后端调用添加令牌请求）。

用户通过身份验证后，您的应用将具有访问令牌，刷新令牌和ID令牌。您可以直接在应用程序后端使用这些令牌。如果您的应用程序后端需要在用户上下文中调用其他API，则可以通过将从本机客户端应用程序获取的访问令牌交换为另一用户的访问令牌，从而将访问令牌交换给另一个资源。访问令牌最初是被授予的（实际上，有一个示例可以做到这一点：the token request）。

对于Angular2应用程序，我建议结合一些似乎增加了对Angular2的支持的包装器库（例如active-directory-dotnet-webapi-onbehalfof）来看一下ADAL for JavaScript库。