【.com快译】众所周知，在不同系统的不同应用场景下，开发者往往会使用完全不同的专有认证方式。本文将为您介绍RESTAPI和微服务世界中常用的四种身份验证方法。身份验证和授权概念在深入研究身份验证方法之前，让我们从概念上看一下身份验证和授权。身份验证是实体证明其身份的时候。换句话说，为了证明他们自称是谁，请求者持有由可信机构签发的身份证明并将其作为证据出示。授权是一个完全不同的概念。简单来说，授权就是一个实体需要证明自己有访问权。也就是说，为了证明你有提出要求的权利，你有一张工作卡，可以让你打开工作区的部分门，但不是全部。总结一下：认证就是证明正确的身份；而授权就是允许某种行为。例如：虽然API可以验证您的身份，但它不能授权您发出特定请求。四种常用的认证方式了解了认证的定义，我们再来看一下RESTAPI中四种常用的认证方式。HTTPBasicAuthenticationSchemeHTTP协议的安全认证方案包括以下几种：Basic（基本）Bearer（承载）Digest（摘要）OAuth等……HTTP的基本认证是最直接、最简单的方法。发件人将Base64编码的用户名和密码放在请求的标头中。其中，Base64编码技术可以将用户名和密码转换为一组64位字符，保证传输的安全性。由于此方法只使用HTTP标头本身，而不是cookie、会话ID、登录页面和其他专门的解决方案，因此它不需要通信握手或其他复杂的响应系统。以下是请求标头中基本身份验证的示例：Authorization:BasicbG9sOnNlY3VyZQ==由于固有的安全漏洞，如今很少推荐使用HTTP基本身份验证。不记名身份验证（也称为令牌身份验证）是一种涉及不记名令牌（安全令牌）的HTTP身份验证方案。这里的“bearerauthentication”可以理解为一个“tokentoallowaccess”，即允许访问某个资源或URL，甚至是一个加密的字符串。它通常由服务器响应登录请求生成。向受保护资源发出请求时，客户端必须在身份验证标头中发送此令牌：Authorization:Bearer承载身份验证方案最初是作为RFC-6750中OAuth2.0的一部分创建的。但是，它有时会单独使用。与BasicAuthentication类似，BearerAuthentication需要通过HTTPS（即SSL）实现。各种API密钥在RESTAPI安全中，业界广泛使用各种AP??I密钥。当然，此类方法仍不被视为安全措施的良好做法。APIkey的产生是为了补充HTTP基本认证及其体系在认证初期遇到的各种问题。在这种方法中，系统为每个首次使用的用户生成并分配一个唯一值，以表明该用户是系统已知的。因此，当用户试图重新进入系统时，他们持有的唯一密钥（有时由他们的硬件、IP相关数据和来自已知服务器的随机时间因素的组合生成）可用于证明他们确实和之前的注册用户是同一个人。实际上，许多API密钥作为查询字符串中URL的一部分发送。而这些敏感的关键信息很容易被网络上不该访问的人窃取。因此，更好的选择是将API密钥放在身份验证标头中。对应的标准示例为：Authorization:Apikey1234567890abcdef。然而，在实践中，API密钥也可能出现在以下不同的部分：AuthorizationHeaderBasicAuthenticationBodyDataCustomHeaderRequestString因为API密钥非常简单，所以我们可以将它用作某些用例的单一标识符。例如，我们可以限制一个API只有“读”权限，禁止它调用编辑、修改、删除等安全相关的命令。然而，由于任何请求服务的人都需要发送他们的密钥，理论上在网络传输过程中任何不安全的节点都可以接收到密钥，因此必然存在密钥被泄露的风险。暴露，甚至被替换的风险。可见，当你设计RESTAPI的相关认证机制时，需要通过安全测试来排查各种常见的漏洞。OAuth(2.0)尽管OAuth2.0规范比其前身OAuth1.0和1.0a复杂得多，但它不再需要密钥散列来对每个调用进行签名。其中，常见的OAuth实现使用以下一种或两种类型的令牌：访问令牌：就像发送API密钥一样，它允许应用程序访问用户的数据。当然我们也可以设置accesstoken的过期时间。刷新令牌：作为OAuth流程的一部分，刷新令牌用于在其过期时检索新的访问令牌。因为OAuth2结合了身份验证和授权，所以它允许对范围和有效性进行更复杂的控制。OAuth2.0目前是识别个人用户帐户和授予适当权限的合适选择。在该方法中，当用户登录到某个系统时，该系统的请求用户将以令牌的形式提供身份认证信息。然后用户将此请求转发给身份验证服务器，然后由身份验证服务器决定拒绝或允许它。然后，请求者可以在严格限制的范围和有效期内，随时使用目标系统，只需通过令牌验证和检查。可见，由于token在使用一段时间后可以撤销，因此该机制比其他API服务访问控制方式更加安全有效。OAuth2.0的各种流程（flows）OAuth2.0提供了几种适合不同类型API客户端的流程，方便他们从授权服务器获取访问令牌：授权码：这是一个常见的流程，主要服务于服务器端和移动网络应用程序。这类似于用户使用Facebook或Google帐户注册相应网络应用程序的方式。隐式：此流程将要求客户端直接检索访问令牌。虽然用户的凭据不能存储在客户端代码中，但第三方身份验证机制可以轻松访问它们。因此，它适用于不包含任何服务器组件的Web、桌面和移动应用程序。资源所有者的密码：它需要用户名和密码才能登录，并且信任凭证将成为请求的一部分。此流程仅适用于受信任的客户端（例如，API提供商发布的官方应用程序）。客户端凭据：用于“服务器到服务器”身份验证。在大多数情况下，它为用户提供了一种在客户端应用程序中指定其信任凭证的方式，因此它可以在客户端的控制下访问相应的资源。OpenIDConnectOpenIDConnect是OAuth2.0协议之上的一个简单身份层，允许计算客户端根据授权服务器进行的身份认证来验证最终用户的身份，并获得最终用户的个人资料信息。在技??术实现上，OpenIDConnect使用JSON作为数据格式，然后指定一个RESTfulHTTPAPI。OpenIDConnect允许一系列客户端（包括基于Web的客户端、移动客户端和JavaScript客户端）请求和接收经过身份验证的会话和最终用户信息。该规范套件可扩展以支持可选功能，例如身份数据加密、OpenID提供商发现和会话管理。OpenIDConnect定义了一个登录过程，使客户端应用程序能够对用户进行身份验证并获取有关用户的信息（或“声明”），包括：用户名、电子邮件等。同时，用户身份信息将被编码在安全的JSON中Web令牌(JWT)，称为ID令牌。此处的JSONWebToken是一种开放的行业标准(RFC7519)方法，可用于安全地表达各方之间的各种声明。同时，JWT允许用户解码、验证和生成JWT。虽然JWT是一个通用标准，但它实际上是由API驱动的身份验证管理公司Auth()开发的。OpenIDConnect定义了一种称为OpenIDConnectDiscovery的发现机制，其中OpenID服务器在公共URL（通常为https://server.com/openid-configuration）上发布其元数据。此处的URL返回OpenID/OAuth端点的JSON列表、支持的范围和声明、用于签署令牌的公钥以及其他详细信息。客户端可以使用此信息来构造对OpenID服务器的请求。其中使用的字段名称和值在OpenIDConnectDiscovery规范中已经定义。OpenAPI安全方案在OpenAPI规范中，各种API安全方案预先定义了哪些API资源是安全的，它们的具体含义，以及适合在特定API中使用的安全机制类型。因此，在现有的OpenAPI规范中，可以选择不同的标准认证协议，每种协议都有自己的优缺点。1、基础API认证具有以下特点：易于实现，几乎可以支持所有类型的Web服务器。需要发送base-64编码的用户名和密码。没有SSL就无法使用。可以轻松地与其他安全方法结合使用。注意：当不使用加密时，基本身份验证容易受到各种劫持和中间人攻击。因此，请将此身份验证方法与SSL一起使用。2、OAuth1.0（digestscheme）有以下特点：是比较流行的协议，经过长时间的考验。它不仅支持安全签名，而且定义明确。其加密签名包含令牌密钥、随机数和其他基于请求的信息。它不依赖SSL来使用。3.OAuth2（bearertokenscheme）具有以下特点：当前的OAuth2规范不再需要加密的签名、密码和用户名。OAuth2使用称为流的身份验证方案，其中包括：授权代码流。隐式流。资源所有者的密码流。客户端凭证流。4.OpenIDConnectDiscovery具有以下特点：基于OAuth2.0协议。登录流程用于允许客户端应用程序对用户进行身份验证和访问信息。可以使用安全的JSONWeb令牌(JWT)对用户信息进行编码。最后值得一提的是RestCase开发平台，它允许您直观地定义上述各种安全解决方案，让用户无需任何编码知识即可构建和定义整体API。原标题：四种最常用的RESTAPI认证方法，作者：GuyLevin
