REST API认证的四种常用方法

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

【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。

[[273541]]

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中适合使用安全机制类型。

[[273542]]

因此,在现有的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】

责任编辑:赵宁宁 来源: 51CTO
相关推荐

2023-06-19 15:38:38

JavaScripAPI

2017-09-21 13:04:35

数据挖掘分析分析方法数据分析师

2021-08-11 20:17:22

推荐算法系统

2022-07-04 12:07:57

智慧城市智能建筑物联网

2015-05-08 12:24:10

恶意软件逃避技术

2023-08-30 23:41:16

AI框架项目

2023-02-10 11:13:42

网络功耗无线网络设备

2010-10-19 17:40:30

SqlServer主键

2009-12-09 11:03:45

安装Linux

2010-11-04 09:31:21

DB2循环语句

2014-03-17 09:22:43

Linux命令

2022-09-02 14:29:01

JavaScrip数组属性

2010-08-11 16:51:43

职场

2010-08-06 14:28:55

Flex CSS样式

2011-06-22 15:21:08

XML

2020-08-10 00:30:55

备份密码iPhone移动安全

2009-03-31 13:12:30

解析XMLJava

2009-02-25 09:52:14

类型转换.NET 强制转型

2010-03-24 19:09:43

Python语言

2011-05-11 18:16:52

网站收录量
点赞
收藏

51CTO技术栈公众号