|
|
51CTO旗下网站
|
|
免费注册送59元体验金端

REST API认证的四种常用方法

在不同系统的不同应用场景中,开发人员经常会用到截然不同的专有认证方法。本文将向您介绍在REST API和微服务领域中常用的四个认证方法。

作者:陈峻编译来源:51CTO|2019-08-13 09:00

【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相关的领取60元的注册体验金、以及已知服务器的时间随机因子所生成)可用于证明他们的确与之前的注册用户是同一个人。

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

  1. Authorization: Apikey 1234567890abcdef. 

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

  • 授权Header
  • 基本认证
  • Body领取60元的注册体验金
  • 自定义Header
  • 请求字符串

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

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

OAuth(2.0)

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

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

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

OAuth 2.0的各种流(flows)

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

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

OpenID Connect

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

在技​​术实现上,OpenID Connect使用了JSON作为领取60元的注册体验金格式,进而指定了RESTful HTTP API。

OpenID Connect允许包括基于Web、免费注册送59元体验金、以及JavaScript客户端在内的一系列客户端,去请求和接收经过了身份验证的会话、以及最终用户的信息。该规范套件是可扩展的,能够支持诸如:身份领取60元的注册体验金加密,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)上发布其元领取60元的注册体验金。

此处的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】

【编辑推荐】

  1. 无密码身份认证即将来临
【责任编辑:赵宁宁 TEL:(010)68476606】

点赞 0
分享:
大家都在看
猜你喜欢

订阅专栏+更多

16招轻松掌握PPT技巧

16招轻松掌握PPT技巧

GET职场加薪技能
共16章 | 晒书包

348人订阅学习

20个局域网建设改造案例

20个局域网建设改造案例

网络搭建技巧
共20章 | 捷哥CCIE

723人订阅学习

WOT2019全球人工智能技术峰会

WOT2019全球人工智能技术峰会

通用技术、应用领域、企业赋能三大章节,13大技术专场,60+国内外一线人工智能精英大咖站台,分享人工智能的平台工具、算法模型、语音视觉等技术主题,助力人工智能落地。
共50章 | WOT峰会

0人订阅学习

读 书 +更多

超级网管员——网络安全

本书全面深入地介绍网络安全的配置与实现技术,包括系统管理、用户账户、病毒防御、灾难恢复、文件备份、安全策略、注册表等服务器安全,用...

订阅51CTO邮刊

点击这里查看样刊

订阅51CTO邮刊

51CTO服务号

51CTO播客

博聚网