我为什么使用JWT

背景

前段时间做数据平台的鉴权，想了很多种方案，但最后还是选择了JWT来进行身份验证与权限控制。
期间考虑过传统的user/passwd -> session_id，也考虑了随机生成Token，后端再来维护一套权限控制逻辑，甚至打算使用类似kebos这种来实现安全通信，但对于数据平台这种业务，感觉权限控制这里这些方案都有点重量级了。

内网环境相对是安全的，对内网进行混杂模式抓包会被安全的人抓到，所以身份伪造这个问题其实不是那么严重。使用证书这种方式系统消耗又很大，资源利用率不高。

思来想去，发现还是得从我们最初的目的出发，想明白客户到底想要什么，而不是为了高大上而选择难度最高的方案。

我们需要什么

我们要的很简单，区分接口调用方，对接口添加权限控制，无权限、无Token的调用返回400错误，同时对所有请求的入参、出参都进行记录。

简单点就是，我们需要知道 是否有权限的 谁 在什么时候 调用了 什么接口，入参是什么，得到了什么返回。

这就很简单了。

跟鉴权有关的，我们只需要区分出是谁跟是否有权限即可。

结合内网环境相对安全，可提供固定Token、接口访问频繁，鉴权最好与数据库分离，实现横向扩容等原因，JWT便从众多方案中脱颖而出。

使用JWT的原因

1. 鉴权逻辑无需访问数据库，任何情况下都不会击穿缓存打到数据库影响业务；
2. 与数据库解耦，横向扩容性佳，Token发放、验证都可以脱离数据库
3. 同样是提供Token，但JWT中可附带允许的权限/操作，业务无需实现复杂的权限控制逻辑，只需要判断Token中是否有对应权限即可；
4. 数据平台主要的功能就是提供数据访问接口与数据上传接口，没有传统Web应用的那种上下文关系。过重的鉴权逻辑不太符合当前业务特点；
5. 使用多版本私钥，通过更改固定版本签名所用的私钥可以批量废除发出的Token；使用Redis等缓存后亦可实现对单一Token的回收
6. 业务只有上传/拉取这两个操作，只需要区分当前用户是谁即可

结论：什么时候使用JWT比较合适？

1. 没有上下文的环境（有其实也可以，但这样他的优势就没那么大）
2. 只需要区分用户
3. 不想让鉴权用到的数据库成为可能的瓶颈
4. 业务行为简单，只提供curd这类功能
5. 可以实现自动化的Token发放，并且网络环境相对安全