SpringBoot中Token登录授权、续期和主动终止的方案流程分析_Java

springboot项目要写登录注册之类的方案
使用cookie或session的话，它是有状态的，不符合分布式技术架构
使用security或者shiro框架实现起来比较复杂，一般项目无需用那么复杂
使用jwt它虽然是无状态的，也可以载荷用户数据，但还是有很多缺点:
- 缺点1：设置过期时间后，无法强制让它过期，在有效期内它始终可用
- 缺点2：一次性的，如果用户数据有变，只能重新生成新的jwt

以前登录token一般是放在服务端的session中，session有过期时间，也会自动延期，当然我们现在绝大部分项目都不会使用session来存储了。

1、redis+token方案的授权流程

springboot用普通的uuid作为token，返回到前端后，前端每次请求都会带上这个token作为授权凭证。这种方案是能够自动续签，也能做到主动终止。所以很多项目用的都是redis+token方案，简单方便问题少。缺点就是需要依赖redis和数据库。

流程 + lua优化：

设置一个拦截器，不校验登录接口，拦截其他接口
登录接口接收前端传来的用户名密码，去数据库查询该用户名是否存在，该密码是否正确
如果正确则表示登录成功，调用生成token方法，返回token给前端
token使用用户id或账号+时间戳+uuid用md5加密的一串字符串（不建议用其他数据，因为id或账号极少变更的，变更会增加复杂性）
生成后存储到redis，把token当作键，用户数据当作值，并设置过期时间
生成token的方法中，还得防止重复调登录接口，不停生成不同的token，所以先判断数据库中是否存在键，所以保存token键到redis的同时要在redis中再增加一条用户id为键token为值的数据，可以验证该用户是否已经生成过token

springboot demo代码：

接下来是校验其他接口方法，同时也做了验证和续期

2、jwt方案的的授权流程

2.1 jwt带来的续签和终止问题

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

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

2.2 解决jwt自动续签有几个解决方案

每次请求都返回新的token，这种简单粗暴，不存在续签的问题，不过相信很多人不会用，请求量大的话性能损耗也是比较明显。
生成的jwt，不加入过期时间，在服务端redis额外存储一个对应的过期时间，并每次操作延期。这种设计感觉很多余，既然保存到了redis，jwt从无状态变成了有状态，既然能够保存过期时间，为啥不把用户信息都保存到redis中，何必用jwt加密后前后端传来传去没有意义。
临近过期刷新jwt，返回新的token，很多人也采用的是这种方案。