API网关的权限验证实践

1. 概述

公司、个人开发的系统上线后，系统中 API 暴露到网络上会存在一定的安全风险，比如：爬虫、恶意访问、错误访问等。API没有安全性，用户可以任意注册即可无限次访问和调用API，且没有请求与特定用户数据关联的简单方法，就无法防止恶意用户的恶意请求等。

常用 API 接口安全措施如下几种：

（1）数据加密

数据在互联网传输过程很容易被抓包，如果直接传输，那么用户数据可能被其他人获取，导致系统安全性等问题，所以必须对数据加密。常见的做法是对关键字段加密，比如用户密码直接通过 md5 加密。

（2）数据签名

数据在传输过程中经过加密，理论上就算被抓包，也无法对数据进行篡改，但是我们一般加密的部分其实只是在外网，现在很多服务在内网中都需要经过很多服务跳转，如果被攻入内网，则可以在任意节点篡改数据，所以这里的加数据签名可以防止内网中数据被篡改。数据签名就是由发送者产生一段无法伪造的一段数字串，来保证数据在传输过程中不被篡改。md5算法是常用的数据签名算法，其原理是将需要提交的数据通过某种方式组合成一个字符串，然后通过md5算法生成一段加密字符串，这段加密字符串就是数据包的签名。为保证安全性，最后的密钥会在客户端和服务端各备一份。

（3）添加时间戳

经过如上的加密，加签处理，就算拿到数据也不能看到真实的数据；但是有些攻击者不关心真实的数据，而是直接拿到抓取的数据包做恶意请求，以达到攻击的目的。我们可以使用时间戳机制，在每次请求的时候加入当前的时间，服务器端会拿到当前时间和消息中的时间相减，看看是否在一个固定的时间范围内，超过时间差的请求就视为非法请求。

（4）限流机制

如果有用户出现频繁调用接口的情况；这种情况需要给相关用户做限流处理，常用的限流算法包括：令牌桶限流，漏桶限流，计数器限流。令牌桶限流：系统以一定速率向桶中放入令牌，填满了就丢弃令牌；请求来时会先从桶中取出令牌，如果能取到令牌，则可以继续完成请求，否则等待或者拒绝服务。令牌桶允许一定程度突发流量，只要有令牌就可以处理，支持一次拿多个令牌。漏桶限流：按照固定常量速率流出请求，流入请求速率任意，当请求数超过桶的容量时，新的请求等待或者拒绝服务，因此漏桶算法可以强制限制数据的传输速度。计数器限流：这是一种比较简单粗暴的算法，主要用来限制总并发数，比如数据库连接池、线程池、秒杀的并发数；计数器限流只要一定时间内的总请求数超过设定的阀值则进行限流。

（5）黑名单限流

如果此用户进行过很多非法操作，或者说专门有一个中黑系统，经过分析之后直接将此用户列入黑名单，所有请求直接返回错误码。我们可以给每个用户设置一个状态比如包括：初始化状态，正常状态，中黑状态，关闭状态等等；或者我们直接通过分布式配置中心，直接保存黑名单列表，每次检查是否在列表中即可。

常用的安全防范有以下方式：API Keys、Basic Auth、HMAC、OAuth。本文主要讨论基于OAuth协议的API安全验证。本文主要介绍基于OAuth协议（Client Credentials）的实践。

1. 系统架构

下图是一个笔者亲身经历的一个例子，到目前为止，运转良好。API服务服务网关采用基于Kong API网关的实现，认证中心是实现OAuth 2.0协议的权限认证系统，服务提供系统设置基于IP的白名单访问。

OAuth 2.0是一种用户验证和授权用户的流行方法，此方法依赖于身份验证服务器和API服务器进行通信以授予访问权限，在笔者的前面的文章中已经详细阐述OAuth的原理，在这里就不在赘述，想看的读者可以翻看历史记录找到该篇文章。下图标注了详细的流程。

1. JWT令牌的理论

JWT（全称：Json Web Token）是一个开放标准（RFC 7519），它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。如有读者想了解详细的JWT规范，可以访问RFC7519的官方网站：https://datatracker.ietf.org/doc/html/rfc7519。

JWT由3部分组成：标头（Header）、有效载荷（Payload）和签名（Signature）。在传输的时候，会将JWT的3部分分别进行Base64编码后用。进行连接形成最终传输的字符串。JWTString=Base64(Header).Base64(Payload).HMACSHA256(base64UrlEncode(header)+"."+base64UrlEncode(payload),secret)。

下图为一个简单的JWT的解码出来的例子：

以上图为例，JWT的数据结构一般是一个三段式的字符，以“.”隔开：xxxxx.yyyyy.zzzzz。

JWT第一部分是Header头部分，它是一个描述JWT元数据的Json对象，通常如下所示。alg属性表示签名使用的算法，默认为HMAC SHA256（写为HS256），typ属性表示令牌的类型，JWT令牌统一写为JWT。最后，使用Base64 URL算法将上述JSON对象转换为字符串保存。

JWT第二部分是Payload，也是一个Json对象，除了包含需要传递的数据，还有七个默认的字段供选择。分别是，iss：发行人、exp：到期时间、sub：主题、aud：用户、nbf：在此之前不可用、iat：发布时间、jti：JWT ID用于标识该JWT。也可以加上自定义字段。需要注意的是，默认情况下JWT是未加密的，任何人都可以解读其内容，因此如果一些敏感信息不要存放在此，以防信息泄露。JSON对象也使用Base64 URL算法转换为字符串保存。

JWT第三部分是Signature签名。是这样生成的，首先需要指定一个secret，该secret仅仅保存在服务器中，保证不能让其他用户知道。然后使用Header指定的算法对Header和Payload进行计算，然后就得出一个签名哈希。也就是Signature。

那么Application Server如何进行验证呢？可以利用JWT前两段，用同一套哈希算法和同一个secret计算一个签名值，然后把计算出来的签名值和收到的JWT第三段比较，如果相同则认证通过。

JWT的优点包括如下：JSON格式的通用性，所以JWT可以跨语言支持，比如Java、JavaScript、PHP、Node等等。可以利用Payload存储一些非敏感的信息。便于传输，JWT结构简单，字节占用小。不需要在服务端保存会话信息，易于应用的扩展。

1. Kong API网关的JWT令牌应用

下图是Kong认证的实际过程。

如果配置中允许OPTIONS请求，并且请求的方法确实是OPTIONS，放行。

如果配置中设置了匿名消费者，并且有凭证，放行。这里是为了实现多重认证，通过配置匿名消费者来实现逻辑或的认证，此时必须有其他认证插件，当其他认证插件通过，jwt插件就不再验证，若不设置匿名，则既要jwt验证也要其他认证插件验证。

先后从query params，request header中查找token（根据配置的变量），token的格式为\\s*[Bb]earer\\s+(.+)，如果从query params找到就返回了，不会再根据request header找。

如果没有找到token，或者token格式不对，并且不允许匿名，返回401。

如果没有找到token，并且允许匿名，根据配置的匿名的id查询消费者，增加request header：X-Consumer-ID、X-Consumer-Username和X-Anonymous-Consumer=true，id是自动生成的，username是配置时填写的，设置这个消费者的凭证是nil，放行。

如果找到token，且格式合法，jwt解码这个token，验证token的 claim，消费者，签名验证，过期验证，全部通过后，同匿名一样，增加步骤5中的request header，并且清除X-Anonymous-Consumer这个header。

以下是Kong网关集成OAuth插件的例子，首先启用OAuth插件，然后在将插件添加到需要集成权限的Service上。

请求的时候只要在HTTP Header带上“Content-Type:application/json”和“Authorization: Bearer 认证中心申请的JWT令牌”即可访问到所需的资源。

1. Spring Cloud Gateway的JTW令牌应用

Spring Cloud Gateway是Spring官方基于Spring 5.0、Spring Boot 2.0和Project Reactor等技术开发的网关，Spring Cloud Gateway旨在为微服务架构提供一种简单而有效的统一的API路由管理方式。Spring Cloud Gateway作为Spring Cloud生态系中的网关，目标是替代ZUUL，其不仅提供统一的路由方式，并且基于Filter链的方式提供了网关基本的功能，例如：安全，监控/埋点，和限流等。

使用Gateway全局过滤器获取JWT Token后进行用户认证及鉴权。下图为实现该过滤器的代码。

1. JWT令牌应用实例

1、登录获取token

2、将token设置到Request Header后，访问资源服务

3、当没有token访问资源服务时就会返回401

1. 总结

最后讲讲JWT的缺点，任何技术都不是完美的，所以我们得用辩证思维去看待任何一项技术。安全性没法保证，所以jwt里不能存储敏感数据。因为jwt的payload并没有加密，只是用Base64编码而已。无法中途废弃。因为一旦签发了一个jwt，在到期之前始终都是有效的，如果用户信息发生更新了，只能等旧的jwt过期后重新签发新的jwt。

续签问题。当签发的jwt保存在客户端，客户端一直在操作页面，按道理应该一直为客户端续长有效时间，否则当jwt有效期到了就会导致用户需要重新登录。那么怎么为jwt续签呢？最简单粗暴就是每次签发新的jwt，但是由于过于暴力，会影响性能。如果要优雅一点，又要引入Redis解决，但是这又把无状态的jwt硬生生变成了有状态的，违背了初衷。所以印证了那句话，没有最好的技术，只有适合的技术。感谢大家的阅读，希望看完之后能对你有所收获。

本文简单的讨论API权限认证，关于API的限流等，后续将持续分享其他内容。码字不易，欢迎关注、点赞、收藏。