WEB安全(十二)token的续签问题-即动态刷新token,避免用户经常重新登录

本文探讨了两种处理Token过期的策略:每次请求刷新Token和使用accessToken与refreshToken组合。第一种策略可能导致性能下降和黑名单增长,而第二种需要客户端配合,涉及双Token管理。在实现中,需要考虑并发请求时的Token刷新同步问题和用户注销时的安全处理。解决方案包括设置宽限时间和使用定时器预先刷新accessToken。

token有效期一般都设置得很短,那么token过期后如何动态刷新token,避免用户经常重新登录呢?

来看个具体需求:

超过2个小时后,用户没有请求,则需要重新登录。

这个需求一般有两种实现方式。

方式一 每次请求都返回新 token

假设一个 token 的签发时间为 12:00,需求为 2h 未进行请求即过期。则设置有效期 2h,那么每次请求都会把一个 token 换成一个新 token。如果 2h 没有进行请求,那么上一次请求的到的 token 就会过期,需要重新登录。不断签就能一直使用下去。

这种方式实现思路很简单,但开销比较大。

问题一:每次都刷新 token,带来的性能影响如何?

以前每次请求,需要进行一次 token 签名校验,而现在是要签发一个新 token,进行的都是一次签名运算,那么运算量即从 n 变成 2n。

其次,每次刷新都要把旧 token 加入黑名单,会导致黑名单特别大。

问题二:每次都刷新 token,并发请求时会不会因为 token 刷新而导致只有一个请求成功?

答案是确实会导致这个问题,怎么解决呢?设置一个宽限时间,每次 token 刷新后,原来逻辑应该是立刻不可用,现在设置一个宽限时间,让其在 n 秒之内仍然可用即可。

方式二 用户登录返回两个 token

第一个是 accessToken ,它的过期时间 token 本身的过期时间2个小时,另外一个是 refreshToken 它的过期时间更长一点比如为1天。客户端登录后,将 accessToken和refreshToken 保存在本地,每次访问将 accessToken 传给服务端。服务端校验 accessToken 的有效性,如果过期的话,就将 refreshToken 传给服务端。如果有效,服务端就生成新的 accessToken 给客户端。否则,客户端就重新登录即可。

该方案的不足是:

1、需要客户端来配合;

2、用户注销的时候需要同时保证两个 token 都无效;

3、重新请求获取 token 的过程中会有短暂 token 不可用的情况(可以通过在客户端设置定时器,当accessToken 快过期的时候,提前去通过 refreshToken 获取新的accessToken)

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值