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

àì夳堔傛蜴生んèń 2022-11-07 01:50 668阅读 0赞

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

*  JWT的优势在于无状态，也就是生成的Token中本身有存储信息（payload），所以不需要依赖Redis和DB。JWT本身也有有效期参与签名，问题在于这个有效期不能更改，也很好理解如果参与签名的参数（有效期）发生变化，Token也就不一样了。如果有效期不能改变，即便时间设计的再长，也会有到期的时候，而且Token这种设计初衷也不能有效期很长，导致用户在操作过程中Token到期授权失败，这种情况根本是无法接受的。
 *  另外，JWT的Token签发之后，理论上在到期之前是始终有效的，在有些场景下，比如用户更改/重置密码，踢出登录（单一用户登录），都需要让对应用户在其他电脑（终端）上自动退出登录，也就是要让其他的Token马上失效，所以需要额外设计来解决这两个问题。

### （2）非JWT的授权流程 ###

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

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rlc2t5_size_16_color_FFFFFF_t_70][]

### （3）JWT的授权流程 ###

*  解决JWT自动续签有几个解决方案
    
     *  每次请求都返回新的Token，这种简单粗暴，不存在续签的问题，不过相信很多人不会用，请求量大的话性能损耗也是比较明显。
     *  生成的JWT，不加入过期时间，在服务端Redis额外存储一个对应的过期时间，并每次操作延期。这种设计感觉很多余，既然保存到了Redis，JWT从无状态变成了有状态，既然能够保存过期时间，为啥不把用户信息都保存到Redis中，何必用JWT加密后前后端传来传去没有意义。
     *  临近过期刷新JWT，返回新的Token，很多人也采用的是这种方案。
 *  主动终止问题
    
     *  JWT签发后就生效，无法做到主动终止，我的方案还是用到了Redis，把用户id作为key，生成一个用户唯一ID（`用户指纹`）存入Redis，并参与JWT签发过程；
     *  如果更改了密码需要终止其他所有已经签发的JWT，只需要更改这个用户指纹；
     *  在JWT验签过程中，验证用户指纹，如果和JWT中信息不一致授权失败，也就是做到了主动终止JWT的目的。
     *  需要注意的是，在高并发过程中写入用户指纹过程可能要用到分布式锁。

![watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rlc2t5_size_16_color_FFFFFF_t_70 1][]

[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rlc2t5_size_16_color_FFFFFF_t_70]: /images/20221023/50c775fb6893425bbe50cb926ed79b5e.png
[watermark_type_ZmFuZ3poZW5naGVpdGk_shadow_10_text_aHR0cHM6Ly9ibG9nLmNzZG4ubmV0L2Rlc2t5_size_16_color_FFFFFF_t_70 1]: /images/20221023/2cc82576c8ed4e51abdb641d8c776b82.png