JWT登录过期-自动刷新token方案介绍

前言

在前后分离场景下，越来越多的项目使用jwt token作为接口的安全机制,但存在jwt过期后，用户无法直接感知，假如在⽤户操作页⾯期间，突然提⽰登录，则体验很不友好，

所以就有了token⾃动刷新需求。但是这个自动刷新方案，基本都离不开服务端状态存储，JWT推出思想是：去中⼼化，⽆状态化，所以有所违背类似这样的业务，有阿⾥云⾸页，没有做token刷新令牌维护，但是符合对应的思想

⽅案⼀、前端控制检测token，⽆感知刷新

⽤户登录成功的时候，⼀次性给他两个Token，分别为AccessToken和RefreshToken

AccessToken有效期较短,⽐如1天或者5天，⽤于正常请求

RefreshToken有效期可以设置长⼀些，例如10天、20天，作为刷新AccessToken的凭证

刷新⽅案

当AccessToken即将过期的时候，例如提前30分钟，客户端利⽤RefreshToken请求指定的API获取新的AccessToken并更新本地存储中的AccessToken

核⼼逻辑

1. 登录成功后，jwt⽣成AccessToken； UUID⽣成RefreshToken并存储在服务端redis中,设置过期时间
2. 接⼝返回3个字段AccessToken/RefreshToken/访问令牌过期时间戳
3. 由于RefreshToken存储在服务端redis中，假如这个RefreshToken也过期，则提⽰重新登录;

疑问：RefreshToken有效期那么长，和直接将AccessToken的有效期延长有什么区别

答：RefreshToken不像AccessToken那样在⼤多数请求中都被使⽤，主要是本地检测accessToken快过期的时候才使⽤，⼀般本地存储的时候，也不叫refreshToken,前端可以取个别名，混淆代码让攻击者不能直接识别这个就是刷新令牌

缺点：

前端每次请求需要判断token距离过期时间

优点：

后端压力小，代码逻辑改动不⼤

⽅案⼆、后端存储判断过期时间

后端存储AccessToken，每次请求过来都判断是否要过期，如果快要过期则重新⽣成新的token，并返回给前端重新存储，⽐如距离1天或者30分钟就过期的情况，如果⽤户访问对应的接⼝则会更新，但假如没访问则token已经过期则需要重新登录

优点：

前端改动⼩，只需要存储响应http头⾥⾯是否有新的令牌产⽣，有的话就重新存储

缺点：

后端实现复制，且token泄露后容易存在一直保活状态，且前端会存在并发请求，当并发请求收到多个jwt token时，容易生成多个token混乱使用