不懂就学，什么是JWT？ _JWT

文章已收录到我的Github精选，欢迎Star：https://github.com/yehongzhi/learningSummary

起源需要了解一门技术，首先从为什么产生开始说起是最好的。JWT主要用于用户登录鉴权，所以我们从最传统的session认证开始说起。
session认证众所周知，http协议本身是无状态的协议，那就意味着当有用户向系统使用账户名称和密码进行用户认证之后，下一次请求还要再一次用户认证才行。因为我们不能通过http协议知道是哪个用户发出的请求，所以如果要知道是哪个用户发出的请求，那就需要在服务器保存一份用户信息(保存至session)，然后在认证成功后返回cookie值传递给浏览器，那么用户在下一次请求时就可以带上cookie值，服务器就可以识别是哪个用户发送的请求，是否已认证，是否登录过期等等。这就是传统的session认证方式。
session认证的缺点其实很明显，由于session是保存在服务器里，所以如果分布式部署应用的话，会出现session不能共享的问题，很难扩展。于是乎为了解决session共享的问题，又引入了redis，接着往下看。
token认证这种方式跟session的方式流程差不多，不同的地方在于保存的是一个token值到redis，token一般是一串随机的字符(比如UUID)，value一般是用户ID，并且设置一个过期时间。每次请求服务的时候带上token在请求头，后端接收到token则根据token查一下redis是否存在，如果存在则表示用户已认证，如果token不存在则跳到登录界面让用户重新登录，登录成功后返回一个token值给客户端。
优点是多台服务器都是使用redis来存取token，不存在不共享的问题，所以容易扩展。缺点是每次请求都需要查一下redis，会造成redis的压力，还有增加了请求的耗时，每个已登录的用户都要保存一个token在redis，也会消耗redis的存储空间。
有没有更好的方式呢？接着往下看。
什么是JWTJWT(全称：Json Web Token)是一个开放标准(RFC 7519)，它定义了一种紧凑的、自包含的方式，用于作为JSON对象在各方之间安全地传输信息。该信息可以被验证和信任，因为它是数字签名的。
上面说法比较文绉绉，简单点说就是一种认证机制，让后台知道该请求是来自于受信的客户端。
首先我们先看一个流程图：

文章插图

流程描述一下：

用户使用账号、密码登录应用，登录的请求发送到Authentication Server 。
Authentication Server进行用户验证，然后创建JWT字符串返回给客户端。
客户端请求接口时，在请求头带上JWT 。
Application Server验证JWT合法性，如果合法则继续调用应用接口返回结果。

可以看出与token方式有一些不同的地方，就是不需要依赖redis，用户信息存储在客户端。所以关键在于生成JWT，和解析JWT这两个地方。
JWT的数据结构JWT一般是这样一个字符串，分为三个部分，以"."隔开：
xxxxx.yyyyy.zzzzz

文章插图

HeaderJWT第一部分是头部分，它是一个描述JWT元数据的Json对象，通常如下所示。
{"alg": "HS256","typ": "JWT"}alg属性表示签名使用的算法，默认为Hmac SHA256（写为HS256），typ属性表示令牌的类型，JWT令牌统一写为JWT 。
最后，使用Base64 URL算法将上述JSON对象转换为字符串保存。
PayloadJWT第二部分是Payload，也是一个Json对象，除了包含需要传递的数据，还有七个默认的字段供选择。
分别是，iss：发行人、exp：到期时间、sub：主题、aud：用户、nbf：在此之前不可用、iat：发布时间、jti：JWT ID用于标识该JWT 。
如果自定义字段，可以这样定义：

{//默认字段"sub":"主题123",//自定义字段"name":"JAVA技术爱好者","isAdmin":"true","loginTime":"2021-12-05 12:00:03"}

需要注意的是，默认情况下JWT是未加密的，任何人都可以解读其内容，因此如果一些敏感信息不要存放在此，以防信息泄露。
JSON对象也使用Base64 URL算法转换为字符串保存。
SignatureJWT第三部分是签名。是这样生成的，首先需要指定一个secret，该secret仅仅保存在服务器中，保证不能让其他用户知道。然后使用Header指定的算法对Header和Payload进行计算，然后就得出一个签名哈希。也就是Signature 。