JWT的Token自动续期和主动终止

（1）JWT的续签问题和终止问题

• JWT的优势在于无状态，也就是生成的Token中本身有存储信息（payload），所以不需要依赖Redis和DB。JWT本身也有有效期参与签名，问题在于这个有效期不能更改，也很好理解如果参与签名的参数（有效期）发生变化，Token也就不一样了。如果有效期不能改变，即便时间设计的再长，也会有到期的时候，而且Token这种设计初衷也不能有效期很长，导致用户在操作过程中Token到期授权失败，这种情况根本是无法接受的。

• 另外，JWT的Token签发之后，理论上在到期之前是始终有效的，在有些场景下，比如用户更改/重置密码，踢出登录（单一用户登录），都需要让对应用户在其他电脑（终端）上自动退出登录，也就是要让其他的Token马上失效，所以需要额外设计来解决这两个问题。

（2）非JWT的授权流程

以前登录Token一般是放在服务端的Session中，Session有过期时间，也会自动延期，当然我们现在绝大部分项目都不会使用session来存储了。下面的方案用普通的UUID作为token，返回到前端后，前端每次请求都会带上这个token作为授权凭证。这种方案是能够自动续签，也能做到主动终止。我之前的很多项目都采用了这种也没什么大的问题。缺点就是需要依赖Redis和数据库。

 

（3）JWT的授权流程

• 解决JWT自动续签有几个解决方案

  • 每次请求都返回新的Token，这种简单粗暴，不存在续签的问题，不过相信很多人不会用，请求量大的话性能损耗也是比较明显。

  • 生成的JWT，不加入过期时间，在服务端Redis额外存储一个对应的过期时间，并每次操作延期。这种设计感觉很多余，既然保存到了Redis，JWT从无状态变成了有状态，既然能够保存过期时间，为啥不把用户信息都保存到Redis中，何必用JWT加密后前后端传来传去没有意义。

  • 临近过期刷新JWT，返回新的Token，很多人也采用的是这种方案。

• 主动终止问题

  • JWT签发后就生效，无法做到主动终止，我的方案还是用到了Redis，把用户id作为key，生成一个用户唯一ID（用户指纹）存入Redis，并参与JWT签发过程；

  • 如果更改了密码需要终止其他所有已经签发的JWT，只需要更改这个用户指纹；

  • 在JWT验签过程中，验证用户指纹，如果和JWT中信息不一致授权失败，也就是做到了主动终止JWT的目的。

  • 需要注意的是，在高并发过程中写入用户指纹过程可能要用到分布式锁。