【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)的示例：
- Authorization: Basic bG9sOnNlY3VyZQ==
由于固有的安全漏洞，HTTP的基本身份验证如今已很少被建议使用了。
承载认证(也称为令牌认证)是一种涉及到承载令牌(一种安全令牌)的HTTP认证方案。此处“承载认证”可以被理解为“允许访问的令牌”，即：允许访问某个资源或URL，甚至是一个加密的字符串。它通常是由服务器响应某个登录请求而生成的。
在向受保护的资源发出请求时，客户端必须在认证的header中发送该令牌：
- Authorization: Bearer <token>
承载认证方案最初是作为RFC-6750中OAuth 2.0的一部分被创建的。不过，有时它也会被单独地使用到。
与基本身份验证类似，承载身份验证需要通过HTTPS(即SSL)来实现。
API的各种密钥
在REST API安全中，业界广泛地使用到了各种API密钥。当然，此类方法仍不被视为安全措施的优秀实践。
创建API密钥是为了补足HTTP基本身份验证、及其系统在认证早期所碰到的各种问题。在该方法中，系统为每个首次访问的用户生成并分配一个唯一值，以表示用户已被系统所认识。因此，当用户尝试重新进入系统时，他们持有的唯一密钥(有时是由其硬件的组合、IP相关的数据、以及已知服务器的时间随机因子所生成)可用于证明他们的确与之前的注册用户是同一个人。
在实际应用中，许多API密钥是被作为URL的一部分，放在查询字符串中发送出去的。而这些敏感的密钥信息恰恰容易被网络中不该访问的人所剽窃到。因此，更好的选择是将API密钥放在认证header中。其对应的标准示例为：
- 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
【51CTO译稿，合作站点转载请注明原文译者和出处为51CTO.com】
