关于web项目中JWT token会话刷新思考

概述

主要记录下JWT token过期后，前后端token刷新过渡问题。

具体思路

1. 用户通过浏览器访问web系统，进行登录操作后，后台会返回jwt token以及用户信息；同时，会将用户信息设置到redis缓存中（其他缓存亦可，就是为了保存用户的会话信息，可用userID + sessionID做key），并设置缓存过期时间跟jwt中的过期时间一样。
2. 用户下次的请求需要带上JWT token作为请求头，（java后台用拦截器）如果token中过期时间还没过期，就重设redis的过期时间（为原来的过期时间固定值），校验通过，拦截器放行；如果token中的有效验证时间失效但是redis中的会话key依然有效，则依然校验通过并重设redis中的用户过期时间，拦截器放行，此时返回的响应数据中需要带上标记字段（即flag = true），用于判断是否需要页面刷新 JWT token 。
3. 前端接收到接口的响应数据后，也使用拦截器进行拦截，判断是否需要调用后台刷新接口进行 刷新JWT token（即重新生成token），需要则异步刷新（刷新中包括重设redis中的用户会话信息），重设前端的请求头Header；同时，继续放行处理原接口的后续页面逻辑。
4. （这一步可不用考虑，不过可防止多次调用刷新token接口，生成新的token，个人觉得没任何影响，新的token只是更新了会话过期时间，解码后时间没失效就行）针对第三步，前端处理刷新时，为了避免一个用户同一时刻（短时间内）多次调用刷新token接口，前端调用后需要设置一个全局标记，进行不必要的过滤。
5. 如果业务需要的话，刷新的时候，可以考虑旧的token短时间内有效，并与新的token进行共存（类似微信公众号中的 access_token）。这里其实只要新旧token中的过期时间还是有效的，请求验证还是通过的，不必额外做任何处理。

redis的作用：主要是在jwt token中有效会话时间失效，但实际会话应仍然有效的情况下，保证token的刷新过渡平稳。

这样子跟原生session有啥区别：用没用cookie支持的问题。

---更新于 2021/4/14 14:42

token是否一定需要刷新？

其实看了别的开源项目，只要token过期时间设长久一点（12小时、24小时...），根本不必刷新也满足实际需求（不用像session会话那样）

---更新于 2021/3/3 9:55