随着 Web API 角色的重要性日益增加，在可能暴露敏感数据和操作的高价值方案中确保能够信心十足地 使用 Web API 的需求也愈加迫切。
我们可以清楚地看到，整个行业都在寻找一种解决方案，以便为依赖 OAuth 2.0 标准的 REST API 提供 保护。但在实践中，关于应该在项目层面上做些什么，并没有提供详细的指导。此外，Microsoft .NET Framework 中用于保护通信的现有类和工具设计用于特定应用程序类型（基于回发的 Web UX 应用程序）。 它们不适用于 Web API 及其支持的多客户端方案。因此，保护 Web API 的工作在相当程度上已成为一种手 工活动。这些保护工作不见得不安全，但各解决方案之间的差异很大，需要过多的自定义代码。
随着 Visual Studio 2013 的发布，您可以将这些烦恼全都抛诸脑后。此版本引入了来自 Microsoft Open Web Interface for .NET (OWIN) 组件的创新 ASP.NET 工具和安全中间件，它们可为您的 Web API 提 供直接的保护。通过新型 ASP.NET 工具和模板，您可以对 Web API 项目进行配置，使之将身份验证直接外 包给 Windows Azure Active Directory (AD)，从而发出本地项目和 Windows Azure AD 相应条目中的必要 代码。
在本文中，我将向大家介绍如何利用 Visual Studio 2013 的这些新功能创建受 Windows Azure AD 保护 的简单 Web API。我还将向大家展示如何创建一个测试用客户端，从而演示实际使用中的 API。我还将简单 探讨一下后台情况，如果您想要更深入探究此方案的更高级方面，可将其作为起点。
请提供凭据
归根结底，身份验证的功能是在调用方向服务器发送消息时，要求调用方提供可验证其身份或检索其属性 的某种凭据。服务器随后使用这些信息进行授权：确定是否应授予访问权限，以及在哪些方面授予访问权限 。
资源通常将大部分身份验证功能转移给外部服务提供商，通常称为颁发机构或身份提供者。这些提供者负 责繁重的任务，例如让用户登录、分配凭据、处理生命周期流程（如密码恢复）、提供用于用户身份验证的 UI、验证多个协议上的凭据、多身份验证因素管理、欺诈检测等。
将这些功能放到一边，剩下的唯一身份验证任务是确认身份验证是否在所选颁发机构成功通过。此项工作 通常涉及对安全令牌的检查，安全令牌是身份验证成功后颁发机构向调用方发放的数据片段。
安全令牌通常根据特定的格式创建，由将明确识别颁发机构的密钥进行数字签名，并且包含一些将此令牌 唯一绑定到目标资源的数据。资源在收到请求时，会寻找随附的令牌。如果发现一个符合所需验证属性的令 牌，调用方即通过身份验证。
在这一详细级别上，此模式通用性很高，以致于其能够描述许多不同的身份验证方法。我将通过为具体实 体分配高级角色将其应用于此方案。
资源 资源将是我需要保护的 ASP.NET Web API 2 项目。您可以在更细的粒度上应用 身份验证要求。例如，您可以定义操作的子集来进行保护，并让其他操作接受匿名调用方。
颁发机构 我将对 Web API 进行配置，使之将身份验证需求转移到 Windows Azure AD ，后者是面向每个 Windows Azure 订户的平台即服务 (PaaS) 产品。Windows Azure AD 专门用于支持基于 云的应用程序工作负载。此服务保存有关用户（属性和凭据）和组织结构的信息。您可以将其数据与 Windows Server Active Directory 进行同步（如果您选择这样做），或者将数据全部放在云中，无需内部 部署基础结构。
几乎每种在线 Microsoft 服务（Office 365、Intune 和 Windows Azure）都利用 Windows Azure AD 来 满足其身份验证和目录需求。由于有了开放式标准以及对常见协议的支持，您可以从几乎任何应用程序（Web UX、Web API、本机客户端、服务器至服务器等）和平台连接到 Windows Azure AD。我将演示如何在 Windows Azure AD 中注册应用程序，以及利用其 OAuth 2.0 端点。
令牌格式与验证 OAuth 2.0 规范未对任何具体令牌格式作强制要求，但针对 REST 方 案的 JSON Web 令牌 (JWT) 格式 (bit.ly/14EhlE8) 已成为一种事实标准。Windows Azure AD 和 Microsoft OWIN 组件均支持 OAuth 2.0 流中的 JWT 格式。我之所以提到这一点，主要是为了提供一些背景 信息。JWT 获取和验证机制均由中间件负责，令牌格式对应用程序代码是透明的。
客户端 当资源依靠颁发机构来处理身份验证时，它实际上与客户端实现了分离。用户 （以及客户端应用程序）如何获得令牌则成为用户与颁发机构之间的事情。这对代码的可维护性非常有益， 但如果您想看看 API 的实际效果，仍需要设置一个客户端。您将了解如何在 Windows Azure AD 中注册支持 Web API 的本机客户端，以及如何使用 Windows Azure AD Authentication Library (ADAL) 使 .NET 富客 户端应用程序能够通过 Windows Azure AD 对用户进行身份验证，以及获得令牌，以保护对 Web API 的调用 。
图 1 显示我将构建的解决方案的各个元素。如果您此时看不懂其中的一些标签，不要 担心：当我演示该解决方案的开发过程时，将一一做介绍。
图 1 端到端解决方案的体系结构
创建 Web API 项目
要创建 Web API 项目，需要用到 Visual Studio 2013 中新的 ASP.NET 工具和模板。打开 Visual Studio，新建一个 ASP.NET Web 应用程序项目。在新建项目对话框中，选择 Web API 模板。单击“更 改身份验证”按钮。
将显示可为 Web API 选择的现成的身份验证方式，如图 2 所示。选择组织帐户，您 可以借此将 Windows Azure AD 作为颁发机构。（有关所有选项的更多信息，请参见 bit.ly/1bhWngl。）此 处的目标是收集从身份管理角度而言非常重要的 Web API 特性信息，并决定配置哪个 Windows Azure AD 实 例（通常称为“租户”）来处理身份验证。
图 2 组织帐户身份验证对话框