作者:仰望天空TL | 来源:互联网 | 2023-07-26 10:39
原文链接:https:blog.csdn.neta704397849articledetails90216739token认证,生成的token过一段时间就会失效(不要故意把时间设
原文链接:https://blog.csdn.net/a704397849/article/details/90216739
token认证,生成的token 过一段时间就会失效(不要故意把时间设的很长,这样不安全,token变得毫无意义!),用户需要重新登录获取token。用户经常使用客户端,使用过程中 由于token到期 客户端跳转到登录界面要求登录,这样体验极差!比如: token有效期2h,用户一直在使用客户端,使用过程中token到期跳转到登录页面邀请重新登录。第一次忍了,过了2个小时又要重新登录! 用户:MDZZ,再见。
为了解决上述 token过期了活跃用户需要在登录页面重新登录 问题,我们需要token刷新 。(注意:‘活跃’ 这个词).
在介绍双token刷新怎么实现之前,我们需要了解一个问题: 什么时候需要用户跳转登录页面重新登录?
token过期了就需要用户跳转登录页面重新登录? 显然不是的,如果是 不活跃用户 token过期了,确实需要跳转登录页面重新登录。 但是 活跃用户 ,就算token过期了,也不应该跳转登录页面。
细心的话,会发现我在上述过程中 强调了很多次 ‘活跃用户’ , 那么什么样的用户才算活跃用户?
‘活跃用户’
在 access_token创建开始时间点 到 2*access_token实效 的 时间内认为用户是活跃的。
下面是解释:
access_token有效期时长et
活跃用户时长at ,即用户在一次正常操作客户端后的at时间内都是活跃。 ( at >= et , 因为:用户access_token在有效期内我们认为用户是活跃 。)
为什么 at >=et ?
当用户登录后at = et 能满足: 用户access_token在有效期et内我们认为用户是活跃
当用户在登录后access_token结束前的某个点操作一次客户端后, at = et 还是能满足: 用户access_token在有效期et内我们认为用户是活跃 。
如下图
当用户登录后at > et 能满足: 用户access_token在有效期et内我们认为用户是活跃
当用户在登录后access_token结束前的某个点操作一次客户端后, at > et 还是能满足: 用户access_token在有效期et内我们认为用户是活跃。
如下图:
当用户登录后at 如下图:
由上3个假设 at=et成立,at>et成立,at=et
总结:
若access_token有效期时长et ,活跃用户时长at ,那么有 at >=et ,且用户每次正常操作客户端后用户活跃时间应刷新(即用户一次正常操作客户端后的at时间内都是活跃的), 所以可以认为 [access_token创建开始时间点 ,2*access_token有效时长 ] 时间内用户是活跃的
声明: 本篇文章所指的 活跃用户 参照的是token有效期,不要和读者自己项目中活跃用户的定义 强行作比较。
操作一次客户端是指有请求服务器的操作。
双token的刷新 access_token和refresh_token
第一次用账号密码登录服务器会返回两个 token : access_token 和 refresh_token,时效长短不一样。短的access_token 时效过了之后,发送时效长的 refresh_token 重新获取一个短时效token,如果都过期,就需要重新登录了。
refresh_token 就是用来刷新access_token 。活跃用户的 access_token 过期了,用refresh_token 获取 新的access_token 。
access_token 和 refresh_token 的有效时间如何设置
为了保证能够刷新活跃用户的access_token , refresh_token 的有效时间 不能小于 用户活跃时间点
假设 access_token 有效时间是 et ,那么用户在 [ access_token 起始时间点 ,2*et ] 时间内用户是活跃的 ,由此可知 refresh_token 的有效时间 >= 2 * access_token 的有效时间
一般,refresh_token 的有效时间 > 2 * access_token 的有效时间
比如,access_token 实效7天,那么 refresh_token 实效可以给15天,也可以给30天
当然,access_token和refresh_token 的时长具体多少,需要根据环境决定,如涉及到金钱的 银行客户端,12306客户端等 token时长都很短,而普通app客户端的token可以是几天甚至上月.
刷新refresh_token
每次 刷新access_token 时判断 refresh_token 是否快过期 [ refresh_token 剩余有效时间 <= 2*access_token实效],如果是,那就连refresh_token 也刷新。
如果希望降低 刷新refresh_token 频率,可以将 refresh_token 实效提高
access_token数值选择
access_token的有效期是7200秒(两小时),在有效期内,可以一直使用,只有当access_token过期时,才需要再次调用接口获取access_token。在理想情况下,每天只需要获取12次,即每2小时获取一次。如果在有效期内,再次获取access_token,那么上一次获取的access_token将失效。
如果每次发送客服消息、获取用户信息、群发消息之前都要先调用获取access_token接口得到接口访问凭证,这显然是不合理的,一方面会更耗时(多了一次接口调用操作),另一方面access_token的调用也存在限制。
因此,在实际应用中,需要将获取到的access_token存储起来,然后定期调用access_token接口更新它,以保证随时取出的access_token都是有效的。
对于access_token的存储,可以考虑存储在文件、数据库或内存中。具体采用哪种存储方式,需要根据项目实际情况而定。如果只有一台服务器,直接将access_token存储在内存中是最简便有效的方式。