浅谈 REST API 身份验证的四种方法

在平时开发中，接口验证是必须的，不然所有人都能请求你的接口，会带来严重的后果，接口验证一般有四种方法：

让我们直接开始！

TOC

什么是认证和授权？

在开始谈接口验证前，我们有必要先了解一下认证和授权。

认证

认证，简单来说就是验明身份，就像我们的身份证一样，警察在查户口的时候会看一下我们的身份证，证明“你确实是你”。

鉴权

鉴权，简单来说就是看你是否有权限做某些事。就像你在公司一样，有些代码仓库你是没有权限写的，只有读的权限。

认证和鉴权对比

• 认证：检查你的身份

• 鉴权：检查你是否有权限做某些事

1、HTTP 认证

HTTP身份认证方案一共有10种，分别是：

目前最常用的就是前两种：

• 基本认证
• 令牌认证

下面我们简单介绍一下这两种认证：

基本认证

基本认证，顾名思义，是一种非常基本的认证方式，它是直接把密码放在了请求头中了，比如：

Authorization: Basic fasgfkaskjg8798f=

一般来说会将用户名和密码进行编码，不过即使经过编码，也不安全，稍微专业的人猜猜就知道用啥编码方式了，然后解码一下，基本上就跟明文没有啥区别。

2、令牌认证

令牌认证，就是准确的说应该是“Bearer authentication”，Bearer意思就是承载的意思，那么令牌认证可以理解为承载有权访问某资源的令牌。

这个令牌你就当做是古代的城池令牌，比如你是一个战士，你想调用兵力，必须持有某某令牌，每个令牌的权利范围不一样，令牌由朝廷统一发放。

在这里我们可以看出令牌认证有以下特点：

• 令牌的权限可控（不同令牌调用的兵力数量不一样）
• 令牌由服务端生成（朝廷）

令牌认证举例：

Authorization: Bearer WmLkiNzaZuR5aas4m+FE429wWpo=

其中WmLkiNzaZuR5aas4m+FE429wWpo=就是token。

3、API密钥认证

api密钥认证使用率非常高，而且也非常灵活，我们先来看一下API密钥认证是如何工作的：

如图：

1. 客户端先去向授权服务器请求到API KEY
2. 生成后的KEY可以入库记录
3. 客户端访问API服务的带上API KEY

此API KEY 由数字和字母组成，一般至少 30 个字符长

API KEY 举例

Authorization: Apikey fa34sfs32wrwr3432wfa3532tfsaf3f

API KEY使用的时候完全取决于开发者，可以存放在header、body甚至查询参数中，总而言之使用非常简单。

API KEY缺点

API KEY实际意义上并不是授权，有人还是可以获取 API 密钥并获得对他们可用的所有信息的访问权限，就像使用 HTTP 基本身份验证一样，API 密钥只是消除了攻击者猜测进入系统的方式的能力，但是，如果有一个不安全的服务器并且攻击者能够获得一些 API 密钥，那么安全性就不复存在。

3、OAuth (2.0)

OAuth，英文全称：Open Authentication,，中文意思就是开放式身份验证。

我们先来看一下OAuth的工作原理：

如图：

1. 客户端向资源服务器请求授权，这个时候通常就是以用户名和密码进行登录
2. 授权通过后，资源服务器同意客户端授权许可
3. 客户端拿着资源服务器授权许可去认证服务器申请令牌
4. 认证服务器验证授权通过后给客户端生成令牌
5. 客户端拿着令牌请求资源服务器
6. 资源服务器验证令牌的有效时间
7. 验证令牌无误且有效后，向客户端返回其请求的资源

令牌通常具有有限的范围（意味着用户可以对其进行身份验证的系统数量有限）和有效期（意味着令牌在一定时间后过期）

4、OpenID Connect

OpenID Connect，英文缩写：OIDC，是一个 OpenID 基金会 (OIDF) 标准，它是基于 OAuth 2.0 框架之上的身份验证协议，允许在用户尝试访问受保护的 HTTPs 端点时验证用户身份。

OpenID Connect 支持所有类型的客户端，包括基于 Web 的客户端、移动客户端和 JavaScript 客户端。

为啥会出现OpenID Connect？

最大的原因就是OAuth 2.0 本质上是一种授权协议，试想一下这样的场景：有多个资源服务器，你从一个资源服务器上得到授权并且拿到token，你就可以用这个token去访问跟此资源服务器授权类型的网站，这种就是极其不安全的，这就是跨站点访问密码。

这个是啥意思呢？

因为OAuth 2.0是跟用户信息绑定的，认证服务器在验证完授权服务器的信息无误后就会生成一个跟用户信息相关的token，这个token包含了相应的访问范围，这个可以看OAuth (2.0)画的那张图。

举个最简单的生活例子，比如有个军事重地，需要刷卡才能进，那么想要进去，肯定想到先去办张有进入权限的卡，这个卡是跟某某将军的身份证绑定，你通过某种手段拿到了将军的身份证，办理人员只认身份证，身份证无误，给你办了这张卡，你大摇大摆的拿着这张卡进入到军事基地开始谋划大事。

这个就是OAuth 2.0最大的问题：为啥在刷卡进入的时候不验证一下，你到底是不是那个将军？

所以OpenID Connect出现了！

至于OpenID Connect工作原理，本文暂时不做展开，内容太多了，如果大家有需要，可以在评论区告诉我，我视人数看是否值得一写，这块还是蛮难的。

总结

本文介绍了四种rest api身份验证方法：

• HTTP认证
• 令牌认证
• OAuth 2.0认证
• OpenID Connect认证

最不安全的就是HTTP认证中的基本认证，常用一般是令牌认证、OAuth 2.0认证，其中最大的赢家还是OAuth 2.0认证，实现起来比较快速、容易，而且扩展性比较强。OpenID Connect认证最为可靠，是OAuth 2.0的升级，现在也慢慢流行起来！