【51CTO.com快译】众所周知，在不同系统的不同应用场景中，开发人员经常会用到截然不同的专有认证方法。本文将向您介绍在REST API和微服务领域中常用的四个认证方法。

身份验证与授权的概念

在深入介绍认证方法之前，先让我们从概念上来了解一下身份验证与授权。

• 身份验证是指实体证明自己的身份。换句话说，为了证明自己所声称的身份，请求者持有由受信任的机构所颁发的身份证明，并将作为证据提供出来。
• 授权则是一个完全不同的概念，简单来说，授权是指实体需要证明自己有权去访问。换句话说，为了证明自己有权提出请求，您通过持有某张工作卡，来打开工作区域中的一部分门禁，但并非全部。

综上所述：身份验证是要证明正确的身份;而授权则是要允许某种行为。例如：某个API虽然能够认证您的身份，但无法授权您发出某种特定的请求。

四种常用的认证方法

理解了身份验证的定义，下面让我们看看在REST API中常用的四种认证方法。

HTTP基本认证方案

HTTP协议的安全认证方案包括如下：

• 基本(Basic)
• 承载(Bearer)
• 摘要(Digest)
• OAuth和其他......

HTTP的基本身份验证是一种最直接且最简单的方法。发件人将经过了Base64编码的用户名和密码放入请求的header。其中，Base64编码技术可将用户名和密码转换为64个字符集合，以确保传输的安全。

由于此方法只用到了HTTP header本身，而并非cookie、会话ID、登录页面、以及其他专业的方案，所以它不需要通信握手、或其他复杂的响应系统。

以下是一个请求header中基本认证(Basic Auth)的示例：

1. Authorization: Basic bG9sOnNlY3VyZQ== 

由于固有的安全漏洞，HTTP的基本身份验证如今已很少被建议使用了。

承载认证(也称为令牌认证)是一种涉及到承载令牌(一种安全令牌)的HTTP认证方案。此处“承载认证”可以被理解为“允许访问的令牌”，即：允许访问某个资源或URL，甚至是一个加密的字符串。它通常是由服务器响应某个登录请求而生成的。

在向受保护的资源发出请求时，客户端必须在认证的header中发送该令牌：

1. Authorization: Bearer <token> 

承载认证方案最初是作为RFC-6750中OAuth 2.0的一部分被创建的。不过，有时它也会被单独地使用到。

与基本身份验证类似，承载身份验证需要通过HTTPS(即SSL)来实现。

API的各种密钥

在REST API安全中，业界广泛地使用到了各种API密钥。当然，此类方法仍不被视为安全措施的优秀实践。

创建API密钥是为了补足HTTP基本身份验证、及其系统在认证早期所碰到的各种问题。在该方法中，系统为每个首次访问的用户生成并分配一个唯一值，以表示用户已被系统所认识。因此，当用户尝试重新进入系统时，他们持有的唯一密钥(有时是由其硬件的组合、IP相关的数据、以及已知服务器的时间随机因子所生成)可用于证明他们的确与之前的注册用户是同一个人。

在实际应用中，许多API密钥是被作为URL的一部分，放在查询字符串中发送出去的。而这些敏感的密钥信息恰恰容易被网络中不该访问的人所剽窃到。因此，更好的选择是将API密钥放在认证header中。其对应的标准示例为：

1. Authorization: Apikey 1234567890abcdef. 

不过，在具体实践中，API密钥也可能会出现在如下不同的部分中：

• 授权Header
• 基本认证
• Body数据
• 自定义Header
• 请求字符串

由于API密钥非常简单，因此我们可以将其作为单个标识符，运用到某些用例中。例如，我们可以通过限制某个API只具备“读取”权限，而禁止它调用编辑、修改或删除等安全相关的命令。

不过，由于任何请求服务的人都需要发送其密钥，而从理论上说，该密钥在网络传输的过程中可能会被任何不安全的节点所接收到，因此这势必存在着密钥被暴露、甚至是被替换的风险。可见，您在设计REST API的相关认证机制时，需要通过安全测试，来检查各种常见的漏洞。

OAuth(2.0)

虽然OAuth 2.0规范比起其先前的OAuth 1.0和1.0a版本要复杂得多，但是它不再需要使用keyed哈希，来签名每一个调用了。其中，常见的OAuth实现方式会用到如下一到两种令牌：

• 访问令牌：就像发送API密钥一样，它允许应用程序访问用户的数据。当然，我们也可以设置访问令牌的到期时间。
• 刷新令牌：作为OAuth流的一部分，刷新令牌会在过期时，去检索新的访问令牌。由于OAuth2结合了身份验证与授权，因此它允许更为复杂的、范围与有效性的控制。

OAuth 2.0是目前识别个人用户帐户、并授予适当权限的合适选择。在该方法中，用户在登录某个系统时，该系统的请求用户会以令牌的形式提供身份认证的信息。然后，用户将此请求转发给身份验证服务器，该服务器进而做出拒绝或允许的判断。接着，请求者就可以在任何时刻、仅通过令牌验证与检查的方式，在严格限制的范围与有效期内使用目标系统了。可见，由于令牌可以在使用一段时间之后被撤销，因此该机制比其他的API服务访问控制方法来说，更加安全也更加有效。

OAuth 2.0的各种流(flows)

OAuth 2.0通过提供了几种适用于不同类型API客户端的流，以方便它们从授权服务器处获取访问令牌：

• 授权代码：这是一种常见的流，主要服务于服务器端和移动Web应用之间。它类似于用户使用Facebook或Google帐户注册到其对应的Web应用的方式。
• 隐式：这个流会要求客户端直接检索访问令牌。当用户的凭证无法被存储在客户端代码中时，第三方认证机制可以轻松地访问到它们。因此，它适用于不包含任何服务器组件的Web、桌面、以及移动应用。
• 资源所有者的密码：它需要使用用户名和密码来登录，而且信任凭证将成为请求的一部分。这个流仅适用于受信任的客户端(例如，API提供商发布的官方应用)。
• 客户端凭据：适用于“服务器到服务器”的身份验证。在大多数情况下，它提供了允许用户在客户端应用中，指定其信任凭据的方法，因此它能够在客户端的控制下访问相应的资源。

OpenID Connect

OpenID Connect是在OAuth 2.0协议之上的简单身份层，它允许计算客户端根据授权服务器所执行的身份认证，来验证最终用户的身份，并且以互动操作和类REST的方式，获取最终​​用户的配置文件信息。

在技​​术实现上，OpenID Connect使用了JSON作为数据格式，进而指定了RESTful HTTP API。

OpenID Connect允许包括基于Web、移动、以及JavaScript客户端在内的一系列客户端，去请求和接收经过了身份验证的会话、以及最终用户的信息。该规范套件是可扩展的，能够支持诸如：身份数据加密，OpenID Providers发现、以及会话管理等可选的功能。

OpenID Connect通过定义一套登录流程，使得客户端应用程序能够对用户进行身份验证，并获取有关该用户的信息(或“声明”)，包括：用户名、电子邮件等。同时，用户身份信息会在安全的JSON Web Token(JWT)中予以编码，被称为ID令牌。

此处的JSON Web Token是一种开放的、行业标准(RFC 7519)的方法，可用于在各方之间安全地表达各种声明。同时，JWT允许用户进行解码、验证、以及生成JWT。虽然JWT已是通用标准，但是它实际上是由API所驱动的身份验证管理公司--Auth()所开发。

OpenID Connect定义了一种名为OpenID Connect Discovery的发现机制，其中OpenID服务器会在一个公开的URL(通常是https://server.com/openid-configuration)上发布其元数据。

此处的URL会返回包括：OpenID/OAuth端点的JSON列表、支持的范围和声明、用作签名令牌的公钥、以及其他详细的信息。客户端可以使用这些信息，去构建针对OpenID服务器的请求。其中用到的字段名称和值，则在OpenID Connect Discovery 规范中已作定义。

OpenAPI的安全方案

在OpenAPI规范中，各种API安全方案事先定义好了哪些API资源是安全、它们的具体含义，以及在具体API中适合使用安全机制类型。

因此，在现有的OpenAPI规范中，您可以选择不同标准的身份验证协议，而每一种协议都有着自己的优点与缺点。

1. 基本的API身份验证具有如下特征：

• 易于实施，能够支持几乎所有类型的Web服务器。
• 需要发送经过base-64编码的用户名和密码。
• 在缺少SSL时，无法被使用。
• 可以很容易地与其他安全方法进行结合使用。

注意：当没有用到加密时，基本身份验证会很容易受到各种劫持、以及中间人的攻击。因此，请将该认证方法与SSL配套进行使用。

2. OAuth1.0(摘要方案)具有如下特征：

• 是一款经过了长期测试且较为流行的协议。它不但支持安全签名，而且有着明确的定义。
• 其加密签名包含了令牌密钥、随机数和其他基于请求的信息混合。
• 在使用上并不依赖于SSL。

3. OAuth2(承载令牌方案)具有如下特征：

当前的OAuth2规范消除了对于加密签名、密码和用户名的需求。

OAuth2适用于被称为流的身份验证方案，其中包括：

• 授权代码流。
• 隐式流。
• 资源所有者的密码流。
• 客户端凭据流。

4. OpenID Connect Discovery具有如下特征：

• 基于OAuth 2.0协议。
• 用到了登录流，允许客户端的应用程序进行用户身份的验证和信息的访问。
• 用户信息能够通过安全的JSON Web Token(JWT)进行编码。

最后值得一提的是RestCase开发平台，它允许您直观地定义上述各种安全方案，允许用户在没有任何编码知识的情况下，构建和定义整体的API。

原文标题：Four Most Used REST API Authentication Methods，作者：Guy Levin