Azure活動目錄注銷或清除本機應用程序的令牌緩存

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;

問題是它為該令牌生成一小時緩存，如果用戶注銷並再次使用用戶或用戶+錯誤密碼再次進入，則身份驗證只會查找該用戶的緩存並忽略或不驗證密碼。 在一小時的窗口中，任何人都可以使用用戶名進入。

我在這里和許多其他網站上找到了注銷或清除令牌的方法，但這些不適用於我的后端，因為它是無狀態的。 我不管理這些之間的會話或HTTP上下文。 如果有人可以指導解決這個問題，我正在使用Microsoft.IdentityModel.Clients.ActiveDirectory 3.13.1.846版的最后一個程序集，我知道方法AcquireTokenByAuthorizationCodeAsync不會查找緩存但是沒有用於原始憑據的實現。

謝謝你們，希望你能幫助我。

Answer 1

你是以下策略強烈建議反對 。 對於您的應用程序來說，收集用戶名和密碼通常是不好的做法。 此流（ 資源所有者密碼憑據（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 ）。