SpringBoot中Token登录授权、续期和主动终止的方案流程分析
作者：码到三十五
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，很多人也采用的是这种方案。
2.3 解决JWT主动终止问题
- JWT签发后就生效，无法做到主动终止，那还是用到Redis，把用户id作为key，生成一个用户唯一ID（用户指纹）存入Redis，并参与JWT签发过程；
- 如果更改了密码需要终止其他所有已经签发的JWT，只需要更改这个用户指纹；
- 在JWT验签过程中，验证用户指纹，如果和JWT中信息不一致授权失败，也就是做到了主动终止JWT的目的。
- 需要注意的是，在高并发过程中写入用户指纹过程可能要用到分布式锁。
到此这篇关于SpringBoot中Token登录授权、续期和主动终止的方案的文章就介绍到这了,更多相关SpringBoot Token登录授权内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！