其他分享
首页 > 其他分享> > 自动刷新JWT解决方案

自动刷新JWT解决方案

作者:互联网

自动刷新JWT解决方案

背景

在前后分离场景下,越来越多的项目使用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,前端可以取个别名,混淆代码让攻击者不能直接识别这个就是刷新令牌。保证自动刷新的前提下,使用较少的查库次数,防止设置JWT过长的过期时间,对于单端出登录也有一定的拒绝能力,即无法刷新AccessToken。


缺点:前端每次请求需要判断token距离过期时间
优点:后端压力小,代码逻辑改动不大

image-20210825113008585

后端存储判断过期时间

后端存储AccessToken,每次请求过来都判断是否要过期,如果快要过期则重新生成新的token,并返回给前端重新存储,比如距离1天就过期的情况,如果用户访问对应的接口则会更新,但假如没访问则token已经过期则需要重新登录


优点:前端改动小,只需要存储响应http头里面是否有新的令牌产生,有的话就重新存储
缺点:后端实现复杂,且泄露后容易存在一直保活状态,且前端会存在并发请求,当并发请求收到多个jwt token时,容易生成多个token混乱使用

标签:存储,RefreshToken,AccessToken,过期,解决方案,JWT,token,刷新
来源: https://www.cnblogs.com/zhoujianyi/p/15187764.html