token自动续期方案选型讨论

[liuqiufeng]

临过期时间

表示检测到token还有多久过期时启动刷新token流程。不建议设置的太短。比如token30分钟过期，临过期时间应该在10分钟左右。

方案

1. 服务端临过期自动返回

流程：

服务端：

• 每次请求服务端校验token时，根据临过期时间判断token是否即将过期；
• 如果即将过期，则生成一个新的token，填充到response里随响应信息一起返回；
• 在临过期时间内，使用老token的请求都需要生成一个新的token，或维护一个新老token关联关系持续返回该新token。

客户端：

• 检测到返回了新token时，替换掉老token。

2. 客户端临过期刷新

流程：

服务端：

• 提供刷新token接口，生成一个新token；
• 登录和刷新token时，需要返回token过期时间和临过期时间。

客户端：

• 每次请求前根据token过期时间和临过期时间校验是否即将过期；
• 如果即将过期，暂存所有后续请求，先发起刷新token的请求；
• 刷新token完成后，根据顺序取出暂存的请求带新token向服务端发起请求（也包括本请求）。

注：使用了本地时间判断，若本地时间被篡改，特别是本地时间比服务器时间慢时，拦截会失败。

3. 客户端过期后刷新

注：在token过期后一段时间内，允许发起刷新token请求。

流程：

服务端：

• 提供刷新token接口，生成一个新token；
• 校验token时，如果token已过期，则根据是否超出规定时间决定是否允许刷新token；
• 如果允许刷新token，则返回特定错误码告诉客户端发起刷新token请求；
• 如果不允许刷新token，则返回特定错误码告诉客户端跳转登录页。

客户端：

• 收到响应后，根据特定错误码，判断是否要刷新token；
• 暂存所有响应为“需要刷新token”的请求，拦截并暂存后续还未发出的请求，先发起刷新token的请求；
• 刷新token完成后，根据顺序取出暂存的请求带新token重新向服务端发起请求（也包括本请求）。

参考axios实现token无感刷新

[funky-eyes]

我认为方案一比较合适，因为在实现上它比较简单，而且是一种约定式，不需要客户端和服务端过多的改造，我建议在这个方案的基础上能增加一个缓存记录这个token已经通过了置换，避免无限次的重新生成新的token
I think the first scheme is more appropriate, because it is relatively simple in implementation, and it is a convention type, which does not require too much transformation on the client side and server level. I suggest that on the basis of this scheme, a cache record can be added. The token has passed the replacement to avoid unlimited regeneration of new tokens

[lightClouds917]

先按照方案一；后续考虑jwt鉴权，解决恶意反序列化的场景问题；

[ggbocoder]

assign to me plz

[lightClouds917]

v 2.1，thank you