rest_framework_jwt关于Token有效期的说明实验

我们知道rest_framework_jwt在Django项目中的settings.py有如下配置:

JWT_AUTH = {
    # 过期时间
    'JWT_EXPIRATION_DELTA': datetime.timedelta(seconds=60),
    # 是否允许刷新
    'JWT_ALLOW_REFRESH': True,
    # 最大刷新的过期时间
    'JWT_REFRESH_EXPIRATION_DELTA': datetime.timedelta(seconds=120),
}

在阅读剖析了JWT_EXPIRATION_DELTA和JWT_REFRESH_EXPIRATION_DELTA相关token有效期源码后,进行了一些实验,从而用简单的语言来说明这两项配置最终效果。
首先,JWT_EXPIRATION_DELTA,就是Token的过期时间,这个Token,指的是任意一个Token都是这个过期时间,不管它是主Token还是refresh后的子Token,过期时间都为60s(上述设置)。
OK,那么JWT_REFRESH_EXPIRATION_DELTA,也就是注释中的最大刷新的过期时间,到底是什么意思呢,下面是整个Token从签发到刷新到过期的流程:

  1. 通过登录生成第一个主Token——T1,此时时间为7:00:00,T1有效
  2. 20s后,通过refresh,生成一个子Token——T2,此时时间为7:00:20,T1和T2都有效
  3. 60s后,T1过期,无法通过T1认证以及再refresh一个新的Token,此时时间为7:01:00,T2有效,T1完全失去作用
  4. 80s后,T2过期,此时时间为7:01:20,T1、T2均完全失去作用

大致流程大家已经清楚了,整个实验过程中,只有JWT_EXPIRATION_DELTA在发挥作用,一个Token从生成到失效,都逃不过60s的生命周期,且也只能在自己“活着”的时候,去refresh一个新的Token。这是因为我们上述设置中,JWT_EXPIRATION_DELTA的时间比JWT_REFRESH_EXPIRATION_DELTA的时间短,而JWT_REFRESH_EXPIRATION_DELTA其实是在Token生效期内的另一时间段。
将其两个时间倒换,效果如下:

  1. 通过登录生成第一个主Token——T1,此时时间为7:00:00,T1有效
  2. 40s后,通过refresh,生成一个子Token——T2,此时时间为7:00:40,T1和T2都有效
  3. 60s后,T1无法再refresh一个新的Token,但仍然属于有效期,此时时间为7:01:00
  4. 100s后,T2无法再refresh一个新的Token,但仍然属于有效期,此时时间为7:01:40
  5. 120s后,T1过期,无法通过T1认证,此时时间为7:02:00,T2认证有效,T1完全失去作用
  6. 160s后,T2过期,此时时间为7:01:20,T1、T2均完全失去作用

本文链接:

https://www.zaigie.com/archives/382/