JWT 的 Token 过期时间为什么没有生效

男娘i 2022-09-13 13:28 295阅读 0赞

在我第一次在 DRF（Django REST Framework）中使用 JWT 时，感觉 JWT 非常神奇，它即没有使用 session、cookie，也不使用数据库，仅靠一段加密的字符串，就解决了用户身份验证的烦恼。

直到我遇到了一个当时百思不得解的问题，才揭开了它的神秘面纱。

当时遇到的问题就是，无论怎么设置 JWT TOKEN 的过期时间，都没有生效，即使设置为 1 秒后过期，过了 1 分钟，TOKEN 还是可以正常使用，重启 Django 服务也不行。

没有别的办法，我就硬着头皮去追着源码，看看 JWT 是怎么判断 TOKEN 是否过期的。

具体的方法就是，深度优先追溯 JWT 代码的源头。在 DRF 中，配置了 DEFAULT\_AUTHENTICATION\_CLASSES 就是 JWT：

![f70c21dfa39bfc0ca496693cd02e233f.png][]

直接定位至这个类，发现它继承了 BaseJSONWebTOKENAuthentication

![78b7011226dcc132991f4118fc7c457c.png][]

然后看 BaseJSONWebTOKENAuthentication，发现有一段判断过期的逻辑：

![1d3043a70e0727fa3ad352cda0ad3842.png][]

继续展开 jwt\_decode\_handler 这个函数，发现它调用了 jwt.decode 函数

![dbebd01f0c3607a64aed4a543b924e3b.png][]

展开 jwt.decode 函数，发现它调用了函数 `_validate_claims`

![1bfb0d25c561343bee3717d6098335a5.png][]

函数 `_validate_claims` 又调用了 `_validate_exp`，

然后展开 `_validate_exp`，找到了这段：

![56bedba036b5361e8f4d8fd9dc165218.png][]

发现过期时间 exp 来自 payload，payload 又来自 TOKEN 本身：

![d2b87db97fa0375da6ba17c9e5750d17.png][]

至此谜底揭开，原来，TOKEN 的过期时间其实被编码在了 TOKEN 本身，服务器收到 TOKEN 时先进行解码，解码出过期时间，然后和当前时间进行对比，如果当前时间比较小，说明没有过期，TOKEN 就是有效的，否则返回客户端 "Signature has expired."

我 Debug 出了这个 TOKEN 的过期时间 exp，发现这个 exp 是修改 JWT\_EXPIRATION\_DELTA 之前的那个过期时间，**原来修改 JWT\_EXPIRATION\_DELTA 之后需要重新生成 TOKEN，这样的过期时间才会按照新的来。**

### 至此，JWT 的原理已经非常清晰了： ###

用户第一次登录时，服务器（JWT）会获得用户名、用户 id，在加上设置的过期时间构建 payload：

payload = {
            'user_id': user.pk,
            'username': username,
            'exp': datetime.utcnow() + api_settings.JWT_EXPIRATION_DELTA
        }

然后将 payload 用设置好的算法使用私钥加密成 token

def jwt_encode_handler(payload):
        key = api_settings.JWT_PRIVATE_KEY or jwt_get_secret_key(payload)
        return jwt.encode(
            payload,
            key,
            api_settings.JWT_ALGORITHM
        ).decode('utf-8')

token 返回至客户端后，客户端缓存该 token，然后每一次请求时都带上该 token。

服务器在收到请求时先验证该 token，验证的过程就是对 token 进行逆向解码：

def jwt_decode_handler(token):
        options = {
            'verify_exp': api_settings.JWT_VERIFY_EXPIRATION,
        }
        # get user from token, BEFORE verification, to get user secret key
        unverified_payload = jwt.decode(token, None, False)
        secret_key = jwt_get_secret_key(unverified_payload)
        return jwt.decode(
            token,
            api_settings.JWT_PUBLIC_KEY or secret_key,
            api_settings.JWT_VERIFY,
            options=options,
            leeway=api_settings.JWT_LEEWAY,
            audience=api_settings.JWT_AUDIENCE,
            issuer=api_settings.JWT_ISSUER,
            algorithms=[api_settings.JWT_ALGORITHM]
        )

解密使用同样的算法，使用公钥或私钥进行解密，解密成功且不过期，则认为用户有权限访问，正常返回。

## 最后 ##

这个问题至少花了我半个小时的时间，如果你遇到这种情况，能瞬间明白其中缘由，那本文的目的就达到了。

源码之下无秘密，遇到问题，去看源码可能不是解决问题最快的方法，却是提升自己最快的方法。很多开源软件设计模式的应用都非常值得我们学习，比如 DRF 的模块设计，通过 mixins 组合来实现灵活可扩展的 APIView，通过子类传入相关的 class 来实现用户自定义的功能。如何写出灵活可扩展、高内聚低耦合、符合开闭原则的程序，阅读开源代码，是一个非常高效的学习方式。

当然了，这需要先对设计模式有一个系统的学习，让自己有一双慧眼，不然就是守着金山不自知。

如果有帮助，欢迎点赞、在看、关注

[f70c21dfa39bfc0ca496693cd02e233f.png]: /images/20220828/ad1be6a1cb7543f8b140ca210f759676.png
[78b7011226dcc132991f4118fc7c457c.png]: /images/20220828/8aaa00ef39f9451c9036ba777e51e860.png
[1d3043a70e0727fa3ad352cda0ad3842.png]: /images/20220828/079c2d1391b14ebba2a47708d9985eb3.png
[dbebd01f0c3607a64aed4a543b924e3b.png]: /images/20220828/748645e747d64c1894edadb123446d9d.png
[1bfb0d25c561343bee3717d6098335a5.png]: /images/20220828/bce5735df0bc43979c4685b3d64d0903.png
[56bedba036b5361e8f4d8fd9dc165218.png]: /images/20220828/35d35e46cb9e4a558eba65fdc756ef04.png
[d2b87db97fa0375da6ba17c9e5750d17.png]: /images/20220828/7b1b7182a54144b1b307421ce960e148.png