隨著 Web API 角色的重要性日益增加，在可能暴露敏感數(shù)據(jù)和操作的高價值方案中確保能夠信心十足地使用 Web API 的需求也愈加迫切。

我們可以清楚地看到，整個行業(yè)都在尋找一種解決方案，以便為依賴 OAuth 2.0 標(biāo)準(zhǔn)的 REST API 提供保護(hù)。 但在實踐中，關(guān)于應(yīng)該在項目層面上做些什么，并沒有提供詳細(xì)的指導(dǎo)。 此外，Microsoft .NET Framework 中用于保護(hù)通信的現(xiàn)有類和工具設(shè)計用于特定應(yīng)用程序類型（基于回發(fā)的 Web UX 應(yīng)用程序）。 它們不適用于 Web API 及其支持的多客戶端方案。 因此，保護(hù) Web API 的工作在相當(dāng)程度上已成為一種手工活動。 這些保護(hù)工作不見得不安全，但各解決方案之間的差異很大，需要過多的自定義代碼。

隨著 Visual Studio 2013 的發(fā)布，您可以將這些煩惱全都拋諸腦后。 此版本引入了來自 Microsoft Open Web Interface for .NET (OWIN) 組件的創(chuàng)新 ASP.NET 工具和安全中間件，它們可為您的 Web API 提供直接的保護(hù)。 通過新型 ASP.NET 工具和模板，您可以對 Web API 項目進(jìn)行配置，使之將身份驗證直接外包給 Windows Azure Active Directory (AD)，從而發(fā)出本地項目和 Windows Azure AD 相應(yīng)條目中的必要代碼。

在本文中，我將向大家介紹如何利用 Visual Studio 2013 的這些新功能創(chuàng)建受 Windows Azure AD 保護(hù)的簡單 Web API。 我還將向大家展示如何創(chuàng)建一個測試用客戶端，從而演示實際使用中的 API。 我還將簡單探討一下后臺情況，如果您想要更深入探究此方案的更高級方面，可將其作為起點。

請?zhí)峁{據(jù)

歸根結(jié)底，身份驗證的功能是在調(diào)用方向服務(wù)器發(fā)送消息時，要求調(diào)用方提供可驗證其身份或檢索其屬性的某種憑據(jù)。 服務(wù)器隨后使用這些信息進(jìn)行授權(quán)：確定是否應(yīng)授予訪問權(quán)限，以及在哪些方面授予訪問權(quán)限。

資源通常將大部分身份驗證功能轉(zhuǎn)移給外部服務(wù)提供商，通常稱為頒發(fā)機(jī)構(gòu)或身份提供者。 這些提供者負(fù)責(zé)繁重的任務(wù)，例如讓用戶登錄、分配憑據(jù)、處理生命周期流程（如密碼恢復(fù)）、提供用于用戶身份驗證的 UI、驗證多個協(xié)議上的憑據(jù)、多身份驗證因素管理、欺詐檢測等。

將這些功能放到一邊，剩下的唯一身份驗證任務(wù)是確認(rèn)身份驗證是否在所選頒發(fā)機(jī)構(gòu)成功通過。 此項工作通常涉及對安全令牌的檢查，安全令牌是身份驗證成功后頒發(fā)機(jī)構(gòu)向調(diào)用方發(fā)放的數(shù)據(jù)片段。

安全令牌通常根據(jù)特定的格式創(chuàng)建，由將明確識別頒發(fā)機(jī)構(gòu)的密鑰進(jìn)行數(shù)字簽名，并且包含一些將此令牌唯一綁定到目標(biāo)資源的數(shù)據(jù)。 資源在收到請求時，會尋找隨附的令牌。 如果發(fā)現(xiàn)一個符合所需驗證屬性的令牌，調(diào)用方即通過身份驗證。

在這一詳細(xì)級別上，此模式通用性很高，以致于其能夠描述許多不同的身份驗證方法。 我將通過為具體實體分配高級角色將其應(yīng)用于此方案。

資源 資源將是我需要保護(hù)的 ASP.NET Web API 2 項目。 您可以在更細(xì)的粒度上應(yīng)用身份驗證要求。 例如，您可以定義操作的子集來進(jìn)行保護(hù)，并讓其他操作接受匿名調(diào)用方。

頒發(fā)機(jī)構(gòu) 我將對 Web API 進(jìn)行配置，使之將身份驗證需求轉(zhuǎn)移到 Windows Azure AD，后者是面向每個 Windows Azure 訂戶的平臺即服務(wù) (PaaS) 產(chǎn)品。 Windows Azure AD 專門用于支持基于云的應(yīng)用程序工作負(fù)載。 此服務(wù)保存有關(guān)用戶（屬性和憑據(jù)）和組織結(jié)構(gòu)的信息。 您可以將其數(shù)據(jù)與 Windows Server Active Directory 進(jìn)行同步（如果您選擇這樣做），或者將數(shù)據(jù)全部放在云中，無需內(nèi)部部署基礎(chǔ)結(jié)構(gòu)。

幾乎每種在線 Microsoft 服務(wù)（Office 365、Intune 和 Windows Azure）都利用 Windows Azure AD 來滿足其身份驗證和目錄需求。 由于有了開放式標(biāo)準(zhǔn)以及對常見協(xié)議的支持，您可以從幾乎任何應(yīng)用程序（Web UX、Web API、本機(jī)客戶端、服務(wù)器至服務(wù)器等）和平臺連接到 Windows Azure AD。 我將演示如何在 Windows Azure AD 中注冊應(yīng)用程序，以及利用其 OAuth 2.0 端點。

令牌格式與驗證 OAuth 2.0 規(guī)范未對任何具體令牌格式作強(qiáng)制要求，但針對 REST 方案的 JSON Web 令牌 (JWT) 格式 (/14EhlE8) 已成為一種事實標(biāo)準(zhǔn)。 Windows Azure AD 和 Microsoft OWIN 組件均支持 OAuth 2.0 流中的 JWT 格式。 我之所以提到這一點，主要是為了提供一些背景信息。 JWT 獲取和驗證機(jī)制均由中間件負(fù)責(zé)，令牌格式對應(yīng)用程序代碼是透明的。

客戶端 當(dāng)資源依靠頒發(fā)機(jī)構(gòu)來處理身份驗證時，它實際上與客戶端實現(xiàn)了分離。 用戶（以及客戶端應(yīng)用程序）如何獲得令牌則成為用戶與頒發(fā)機(jī)構(gòu)之間的事情。 這對代碼的可維護(hù)性非常有益，但如果您想看看 API 的實際效果，仍需要設(shè)置一個客戶端。 您將了解如何在 Windows Azure AD 中注冊支持 Web API 的本機(jī)客戶端，以及如何使用 Windows Azure AD Authentication Library (ADAL) 使 .NET 富客戶端應(yīng)用程序能夠通過 Windows Azure AD 對用戶進(jìn)行身份驗證，以及獲得令牌，以保護(hù)對 Web API 的調(diào)用。

圖 1 顯示我將構(gòu)建的解決方案的各個元素。 如果您此時看不懂其中的一些標(biāo)簽，不要擔(dān)心：當(dāng)我演示該解決方案的開發(fā)過程時，將一一做介紹。

創(chuàng)建 Web API 項目

要創(chuàng)建 Web API 項目，需要用到 Visual Studio 2013 中新的 ASP.NET 工具和模板。 打開 Visual Studio，新建一個 ASP.NET Web 應(yīng)用程序項目。 在新建項目對話框中，選擇 Web API 模板。 單擊“更改身份驗證”按鈕。

將顯示可為 Web API 選擇的現(xiàn)成的身份驗證方式，如圖 2 所示。 選擇組織帳戶，您可以借此將 Windows Azure AD 作為頒發(fā)機(jī)構(gòu)。 （有關(guān)所有選項的更多信息，請參見 /1bhWngl。）此處的目標(biāo)是收集從身份管理角度而言非常重要的 Web API 特性信息，并決定配置哪個 Windows Azure AD 實例（通常稱為“租戶”）來處理身份驗證。

圖 2 組織帳戶身份驗證對話框

第一個下拉列表確定是只有一個 Windows Azure AD 租戶（業(yè)務(wù)線應(yīng)用程序的典型情況）還是有多個 Windows Azure AD 租戶（適用于軟件即服務(wù) [SaaS] 應(yīng)用程序）使用該應(yīng)用程序。 如果您的應(yīng)用程序?qū)⒂赡局械膯T工使用，通常應(yīng)選擇“單個組織”；或者，如果該應(yīng)用程序?qū)⒂蓙碜远鄠€公司的用戶訪問，通常應(yīng)選擇“多個組織”。 雖然如此，這兩個選項當(dāng)前僅可用于 ASP.NET WebForms 和 ASP.NET MVC 應(yīng)用程序。 當(dāng)前，Web API 項目模板僅支持“單個組織”選項。

“域”文本框標(biāo)識哪個 Windows Azure AD 租戶應(yīng)注冊您的應(yīng)用程序。 其內(nèi)容一般為與您 Windows Azure 訂閱關(guān)聯(lián)的企業(yè)目錄，但實際您擁有管理憑據(jù)的任何目錄都可以（稍后詳做說明）。 在創(chuàng)建時，每個 Windows Azure AD 租戶都有一個采用 yourorganization.onmicrosoft.com 格式的關(guān)聯(lián)三級域。 一般而言，您應(yīng)將該租戶與您已經(jīng)擁有的一個或多個域相關(guān)聯(lián)。 在圖 2 的示例中，我使用自己的域 。

“訪問級別”下拉列表指定此應(yīng)用程序針對該目錄應(yīng)具有哪些訪問權(quán)限。 默認(rèn)值“單一登錄”可使該目錄為您的應(yīng)用程序發(fā)放令牌。 這簡單確認(rèn)了該應(yīng)用程序已注冊。 頒發(fā)機(jī)構(gòu)不會為未注冊的應(yīng)用程序發(fā)放令牌，即使成功通過了身份驗證也是如此。

其他訪問權(quán)限包括“讀取目錄數(shù)據(jù)”和“讀取和寫入目錄數(shù)據(jù)”，它們分別可使應(yīng)用程序查詢該目錄和修改其內(nèi)容。 其通過 Graph API 來執(zhí)行此操作，Graph API 是一種基于 REST 的編程接口，可使來自具有 HTTP 堆棧的任何平臺的應(yīng)用程序獲得對該目錄的委托訪問權(quán)。 我使用默認(rèn)的“單一登錄”訪問級別，并且不演示 Web API 項目中的“圖形”。 但這是 Windows Azure AD 的一項非常強(qiáng)大的功能。 有關(guān) Windows Azure AD Graph API 的更多信息，請參閱 /1aByRLS。

輸入與 Windows Azure AD 租戶關(guān)聯(lián)的域后，單擊“確定”，生成該項目。 該工具將執(zhí)行兩項任務(wù)：

1. 它將訪問所選 Windows Azure AD 租戶，并且添加一個描述正在創(chuàng)建的應(yīng)用程序的條目。
2. 它將發(fā)出 Web API 項目的代碼，添加來自 Microsoft OWIN 組件的必要安全中間件以處理 Windows Azure AD 身份驗證，以及生成必要的初始化代碼以便根據(jù)所選 Windows Azure AD 租戶驗證傳入令牌。

第一個任務(wù)是通過 Graph API 執(zhí)行的（Visual Studio 本身就是 Graph API 的一個客戶端）。 為了在目錄中添加描述正在創(chuàng)建的應(yīng)用程序的條目，該工具需要從該目錄中獲得一個令牌，證明您具有在該目錄中進(jìn)行寫入的必要權(quán)限。 正因為如此，單擊“確定”后 Visual Studio 會向您顯示圖 3 所示的身份驗證提示。

圖 3 帳戶登錄身份驗證提示

您要做的只是輸入該目錄的管理員憑據(jù)。 該工具將驗證您是否具有執(zhí)行所需操作的必要權(quán)限。 單擊“確定”時，Visual Studio 會聯(lián)系 Windows Azure AD 并創(chuàng)建項目文件。

您現(xiàn)在有了配置好的 Web API，可以規(guī)定只有來自指定 Windows Azure AD 租戶的調(diào)用方才能獲得訪問權(quán)限。 讓我們進(jìn)一步了解一下。

轉(zhuǎn)到“解決方案資源管理器”窗格，那里的根目錄中會顯示一個名為 Startup.cs 的文件。 如果您讀過 Howard Dierking 上月發(fā)表的《Katana 項目入門》(msdn.microsoft.com/magazine/dn451439)，應(yīng)當(dāng)知道在應(yīng)用程序啟動時會調(diào)用此文件中的類。 本例中的實現(xiàn)非常簡單：

 
          public partial class Startup
{
  public void Configuration(IAppBuilder app)
  {
    ConfigureAuth(app);
  }
}
        

因為這是標(biāo)準(zhǔn)實現(xiàn)，您應(yīng)當(dāng)能在 App_Start 解決方案文件夾下找到某個類中定義的 ConfigureAuth 方法。 它實際上就是 Startup.Auth.cs 文件。 內(nèi)容如下所示：

 
          public partial class Startup
{
  public void ConfigureAuth(IAppBuilder app)
  {
    app.UseWindowsAzureActiveDirectoryBearerAuthentication(
      new WindowsAzureActiveDirectoryBearerAuthenticationOptions
      {
        Audience = ConfigurationManager.AppSettings["ida:Audience"],
        Tenant = ConfigurationManager.AppSettings["ida:Tenant"]
      });
  }
}
        

app.Use* 命名約定建議該方法在 OWIN 管道中添加一個中間件實現(xiàn)。 此情況下，添加的中間件負(fù)責(zé)檢查傳入請求，查看 HTTP 頭身份驗證是否包含安全令牌。 您就是通過這種方式根據(jù) OAuth 2.0 持有者令牌規(guī)范為請求提供保護(hù)（請參閱 /W4OqA3）。 如果找到令牌，則會通過一些標(biāo)準(zhǔn)檢查對它進(jìn)行驗證：該令牌是否是由預(yù)期的頒發(fā)機(jī)構(gòu)頒發(fā)？ 該令牌在傳輸中是否遭到篡改？ 該令牌是否已過期？

如果此令牌一切正常，則中間件會在一個主體中投射其內(nèi)容，將該主體指定給當(dāng)前用戶，并將控制權(quán)放給管道中的下一個元素。 如果此令牌沒有通過這些檢查，則中間件會發(fā)回相應(yīng)的錯誤代碼。

如果沒有令牌，則中間件只是讓調(diào)用通過，而不創(chuàng)建主體。 一般采用授權(quán)篩選器形式的授權(quán)邏輯利用主體（及其內(nèi)容）是否存在來確定應(yīng)服務(wù)此請求還是拒絕此請求的訪問。

傳遞到中間件的唯一參數(shù) WindowsAzureActiveDirectoryBearerAuthenticationOptions 提供用于確定令牌有效性的設(shè)置。 它在項目創(chuàng)建過程中捕獲原始值，然后將它們保存在 web.config 文件中。 Audience 值是使 Windows Azure AD 識別 Web API 所依據(jù)的標(biāo)識符。 攜帶不同 Audience 的任何令牌用于其他資源，應(yīng)予以拒絕。

Tenant 屬性指示用于外包身份驗證的 Windows Azure AD 租戶。 中間件使用這些信息訪問該租戶，并讀取用于確定令牌有效性的其他所有屬性（例如應(yīng)使用哪個密鑰驗證該令牌的簽名）。

這幾行自動生成的代碼就是通過 Windows Azure AD 對調(diào)用方進(jìn)行身份驗證所需的全部代碼。 在 Web API 項目上要做的事情只剩一件，那就是利用 [Authorize] 修飾您要保護(hù)的方法。 應(yīng)將其添加到 ValuesController 中的所有方法。 （為簡便起見，我使用了模板隨附的默認(rèn)控制器。）

現(xiàn)在，您如何驗證 Web API 的行為符合預(yù)期？ 最簡便的方法是創(chuàng)建測試客戶端。

注冊本機(jī)客戶端

就像 Windows Azure AD 不會為尚未注冊的 Web API 辦法令牌一樣，Windows Azure 也要求請求令牌的所有客戶端進(jìn)行注冊。 為了為特定 Web API 獲取令牌，還必須為已注冊的客戶端明確授予對 Windows Azure AD 中 Web API 的訪問權(quán)。 這些設(shè)計時設(shè)置必須在任何用戶嘗試進(jìn)行身份驗證前就緒。 現(xiàn)在，我將展示如何使用 Windows Azure 門戶注冊客戶端應(yīng)用程序，并創(chuàng)建將其綁定到所創(chuàng)建的 Web API 的權(quán)限。

首先訪問 Windows Azure 門戶。 我將對先前使用的同一帳戶進(jìn)行身份驗證。 為節(jié)省時間，我將直接導(dǎo)航到我的 Windows Azure AD 租戶所對應(yīng)的 Windows Azure 門戶。 通過將租戶域添加到普通門戶地址，可以獲得此 URL，我使用的是 http://manage./cloudidentity。 net。

導(dǎo)航到租戶特定的 URL 比從一般登錄頁面尋找“使用您的組織帳戶登錄”更快。 注意，如果正在使用的 Windows Azure AD 不是您的 Windows Azure 訂閱的管理員或共同管理員，則需要使用您的普通憑據(jù)（Microsoft 帳戶或其他組織實體）登錄到該門戶。

此門戶加載后，從可用服務(wù)列表中選擇 Active Directory 圖標(biāo)，單擊您的目錄，然后單擊“應(yīng)用程序”選項卡。 您將看到包含所創(chuàng)建的全部應(yīng)用程序的列表，包括新 Web API 項目的對應(yīng)條目。 要新建一個條目，請從頁面底部的命令欄單擊“添加”按鈕。 您將看到如圖 4 所示的對話框。 從技術(shù)上講，您能夠定義幾乎任何一種應(yīng)用程序，作為您的 Web API 的有效客戶端。 選擇一個本機(jī)客戶端應(yīng)用程序，然后轉(zhuǎn)到下一個屏幕。

圖 4 Windows Azure Active Directory 門戶上添加應(yīng)用程序向?qū)У牡谝徊?

下一個也就是最后一個屏幕要求您輸入該應(yīng)用程序的重定向 URI。 此 URI 只是在 OAuth 2.0 令牌獲取流程中使用的標(biāo)識符，用于向調(diào)用方發(fā)出信號，指示身份驗證流程的交互部分已完成。 令牌獲取流程的其余部分將繼續(xù)進(jìn)行，無需用戶輸入。 根據(jù)開發(fā)本機(jī)客戶端所在的平臺，您可能需要處理不同的約束。 例如，如果您要使用某些功能，Windows 應(yīng)用商店的應(yīng)用將要求使用 ms-app:// 協(xié)議架構(gòu)（詳細(xì)信息見 /13KrM6i）。

本例中，我將編寫一個不太嚴(yán)格的典型 .NET 桌面應(yīng)用程序。 使用任何有效的 URI 都可以。 我使用的是 https://cloud-identity。 net/myWebAPItestclient，以方便我記憶此客戶端的用途。

一完成此應(yīng)用程序輸入，我就會看到如圖 5 所示的頁面。

圖 5 快速啟動頁面

“更新您的代碼”部分提供了編寫客戶端應(yīng)用程序時將需要的信息。 其中包括重定向 URI 和客戶端 ID（簡單標(biāo)識符）的設(shè)置，在創(chuàng)建向頒發(fā)機(jī)構(gòu)提出的令牌請求時將需要它們。

“配置對 Web API 的訪問”部分提供了一個可轉(zhuǎn)到特定門戶區(qū)域的鏈接，在該區(qū)域中，您可以指定客戶端應(yīng)能夠訪問的 API。 如果點擊此鏈接，將進(jìn)入圖 6 所示的應(yīng)用程序?qū)傩皂撁妗? 底部顯示一個下拉列表，可在其中指定客戶端需要訪問的 Web API。 請注意，該下拉列表同時列出了您定義的應(yīng)用程序和內(nèi)置 API，具體講，是 Windows Azure AD Graph API。

圖 6 Windows Azure Active Directory 門戶上的本機(jī)客戶端應(yīng)用程序?qū)傩皂撁?

選擇 Web API 項目條目，然后單擊“保存”。 執(zhí)行此操作后，Windows Azure AD 中的所有工作即告完成，客戶端就能夠為您的服務(wù)獲取令牌了。 保持瀏覽器頁面打開，因為您將需要該頁面將顯示的一些數(shù)據(jù)。

創(chuàng)建一個簡單的客戶端項目并測試 Web API

您現(xiàn)在終于做好全部準(zhǔn)備，可以創(chuàng)建一個測試客戶端，試一下經(jīng)過身份驗證的 Web API 了。 您可在提供 HTTP 堆棧的任何平臺上創(chuàng)建幾乎任何客戶端類型。 為簡化獲取和維護(hù)令牌的任務(wù)，Microsoft 提供了 ADAL，通過它可輕松針對 Active Directory（Windows Azure 和 Windows Server）進(jìn)行身份驗證，無需成為身份驗證協(xié)議方面的專家。

Microsoft .NET Framework 庫已發(fā)布，現(xiàn)為面向 Windows 應(yīng)用商店的開發(fā)人員預(yù)覽版。 （有關(guān)如何使用 Windows 應(yīng)用商店的應(yīng)用實現(xiàn)此方案的教程，請參閱 /17YtYVg）。最終將發(fā)布面向所有主要客戶端平臺的版本。

由于 .NET 版本已經(jīng)全面上市，在此我將使用該版本。 除不同堆棧間的語法差異外，您在這里學(xué)到的知識同樣適用于其他平臺和應(yīng)用程序類型。 如果您等不及，請記住此處所述方案中的所有通信均遵循開放式標(biāo)準(zhǔn)，并且已詳細(xì)加以記錄。 您能夠非常輕松地對令牌請求邏輯進(jìn)行編碼。 有關(guān)使用 Windows Phone 8 的示例，請參閱 /YatATk。

此項目面向同一解決方案中新的 Windows Presentation Foundation (WPF) 應(yīng)用程序，但您能夠選擇需與用戶交互運行的任何項目類型。 創(chuàng)建項目后，我將添加一個按鈕和一個單擊事件處理程序，用于觸發(fā) Web API 調(diào)用邏輯。

ADAL 作為 NuGet 程序包分發(fā)。 要將其添加到客戶端項目，只需從 Visual Studio 中的“工具”菜單打開程序包管理器控制臺，然后鍵入 Install-Package Microsoft.IdentityModel.Clients.ActiveDirectory -Version 1.0.0。 現(xiàn)在將圖 7 中的代碼添加到單擊事件處理程序中。

 
          private async void btnCall_Click(object sender, RoutedEventArgs e)
{
  // Get token
  AuthenticationContext ac = new AuthenticationContext(
    "https://login.windows.
          net/cloudidentity.
          net");
  AuthenticationResult ar =
    ac.AcquireToken("https://cloudidentity.
          net/WindowsAzureADWebAPITest",
    "a4836f83-0f69-48ed-aa2b-88d0aed69652",
    new Uri("https://cloudidentity.
          net/myWebAPItestclient"));
  // Call Web API
  string authHeader = ar.CreateAuthorizationHeader();
  HttpClient client = new HttpClient();
  HttpRequestMessage request = new HttpRequestMessage(
    HttpMethod.Get, "https://localhost:44353/api/Values");
  request.Headers.TryAddWithoutValidation("Authorization", authHeader);
  HttpResponseMessage response = await client.SendAsync(request);
  string responseString = await response.Content.ReadAsStringAsync();
  MessageBox.Show(responseString);
}
        

如果您覺得這段代碼看起來有些復(fù)雜，請別擔(dān)心。 一會兒一切就都清楚了。

第一行初始化新的 AuthenticationContext。 在該應(yīng)用程序的代碼中，AuthenticationContext 實例代表要使用的頒發(fā)機(jī)構(gòu)。 在這個示例中，該頒發(fā)機(jī)構(gòu)是由 URI https://login.windows. net/[mydomain] 代表的我的 Windows Azure AD 租戶。 您將使用相同邏輯，通過傳遞內(nèi)部部署目錄的 Active Directory 聯(lián)合身份驗證服務(wù) (AD FS) 服務(wù)器的地址，連接到該目錄（有關(guān)詳細(xì)信息，請參閱 /1d553F0）。

第二行向 AuthenticationContext 請求一個令牌。 創(chuàng)建令牌請求的方式有很多 — 每個方案和應(yīng)用程序類型均需要不同的參數(shù)。 在本例中，我要指定希望獲得令牌的資源是我的 Web API。 因此，我傳遞了其 Windows Azure AD 條目的標(biāo)識符。 這是用作 Web API 項目中的 Audience 的同一值。 然后，因為這是請求令牌的本機(jī)客戶端，因此我需要通過在瀏覽器中保持打開的應(yīng)用程序配置頁面，傳入我的客戶端的客戶端 ID 和重定向 URI。

這就是獲得令牌需要執(zhí)行的所有操作。 此代碼的其余部分根據(jù) OAuth 2.0 規(guī)范將該令牌置于正確的 HTTP 頭中，然后執(zhí)行實際調(diào)用。

現(xiàn)在趕快試試這個解決方案吧。 將該解決方案更改為一次啟動所有項目后，按 F5。 執(zhí)行到對 AcquireToken 的調(diào)用后，您就會看到圖 8 所示的身份驗證對話框。 ADAL 負(fù)責(zé)聯(lián)系正確的端點，并在彈出對話框中呈現(xiàn)服務(wù)器提供的身份驗證體驗，無需您編寫任何 UI 代碼。

圖 8 Active Directory 身份驗證庫身份驗證對話框

當(dāng)我提供目錄租戶中的任何有效用戶的憑據(jù)時，我就會獲得一個令牌。 后續(xù)代碼在請求頭中將該令牌提供給 Web API。 安全中間件對其進(jìn)行驗證。 由于所有驗證參數(shù)都匹配，因此它隨結(jié)果發(fā)回 HTTP 狀態(tài)代碼 200，成功完結(jié)此方案的概念證明。

作為有趣的試驗，請再次單擊該按鈕。 此時您將看到，您會立即獲得一個令牌，而不會看到任何提示。 這是因為 ADAL 有一個跟蹤這些令牌的內(nèi)置令牌緩存。 它甚至?xí)诒匾獣r以靜默方式刷新過期的令牌。

下一步該怎么做？

我只是揭開了 Web API、Microsoft OWIN 組件、Windows Azure AD 和 ADAL 眾多功能的冰山一角。 Windows Azure AD 發(fā)放的令牌不僅僅是身份驗證的證明。 它們攜帶了豐富的用戶信息，您能夠從用戶的主體中輕松訪問這些信息，并將它們用于高級授權(quán)邏輯。 身份驗證流程涉及的遠(yuǎn)非此處所示的用戶名和密碼。

從多重身份驗證因素，到聯(lián)合方案中的無縫單一登錄，一切皆有可能。 與 Graph API 相集成可使您訪問豐富的功能。 從簡單的人員選取器功能，到高級的組織結(jié)構(gòu)爬網(wǎng)，您可以通過查詢目錄獲得不僅限于已經(jīng)過身份驗證的用戶的信息。

這些功能可添加到基于云的 Web API 的功能中。 到現(xiàn)在為止，您必須在企業(yè)防火墻后端本地運行這些功能。 在云和內(nèi)部部署的功能對稱性的一個最明顯示例中，您還可以對 Windows Server Active Directory 使用類似的代碼。

當(dāng)然，您還可以將 Web API 發(fā)布到 Windows Azure，無需更改一行代碼 — 這些身份驗證功能將保持正常工作。 您需要做的唯一更改在客戶端項目上進(jìn)行。 服務(wù)的 URL 將根據(jù)新的應(yīng)用程序位置而改變。 但獲取令牌的邏輯可保持完全相同，因為不必將資源標(biāo)識符綁定到該資源的物理地址。