您登录后，服务器如何知道后面的每个请求确实来自您？一种流行的答案是 JSON Web Token，或 JWT，通常发音为“jot”。它是客户端随每个请求发送的一小段经过签名的数据，服务器可以在不接触数据库的情况下检查它。

理解 JWT 的最快方法是构建一个 JWT，然后尝试破坏它。我们仅使用 Python 3.13 上的 Python 标准库来完成此操作，下面的输出来自该运行。 此代码供学习使用。在实际应用中，请使用维护良好的库，因为验证的细节很容易出错。

什么是 JWT？

JWT 是一个开放标准，在 RFC 7519 中定义，用于在两方之间以紧凑字符串的形式传递声明。声明只是一个声明，例如“该用户的 ID 是 42”。由于令牌已签名，因此接收者可以确认是谁颁发的并且没有人更改过它。

想想节日腕带。门口的工作人员检查了你的票一次，然后给你一个很难伪造的乐队。之后，每个摊位只看乐队，无需打电话给售票处。 JWT 的工作方式与 API 的工作方式大致相同。

JWT 登录的工作原理

1. 用户将用户名和密码发送到登录端点。
2. 服务器检查它们并创建签名令牌。
3. 客户端存储令牌。
4. 后面的每个请求都包含它，通常在标头中：Authorization: Bearer <token>。
5. 服务器验证签名和有效期，然后读取声明。

主要好处是在步骤 5 中。服务器不必查找会话，这在许多服务或服务器需要检查相同令牌时很方便。如果您不熟悉 API，请从什么是 API 开始。

JWT 的三个部分

JWT 看起来像随机文本，但它是由点分隔的三个 Base64URL 编码部分。这是我们生成的：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9
.eyJzdWIiOiI0MiIsInJvbGUiOiJ1c2VyIiwiaWF0IjoxNzkzNTAwMDAwLCJleHAiOjE3OTM1MDA5MDB9
.7YfUDH_T-iDh8bMmUT8mmKYwOstzT8Ty--DTTAmQGWM

我们添加了换行符以使其更易于阅读。解码前两部分给出纯 JSON：

Header:  {"alg":"HS256","typ":"JWT"}
Payload: {"sub":"42","role":"user","iat":1793500000,"exp":1793500900}

标准声明

您还可以添加自定义声明，例如 role。时间是 Unix 时间戳，以秒为单位。保持较小的有效负载，因为令牌会随每个请求一起传输。

自己建一个

创建令牌涉及对两个 JSON 部分进行编码，然后使用 HMAC-SHA256 使用密钥对它们进行签名：

import base64, hashlib, hmac, json

SECRET = b"demo-secret-do-not-use-in-production"

def b64url(data):
    return base64.urlsafe_b64encode(data).rstrip(b"=").decode()

def sign(message):
    return b64url(hmac.new(SECRET, message.encode(), hashlib.sha256).digest())

def create_token(payload):
    header = {"alg": "HS256", "typ": "JWT"}
    parts = [
        b64url(json.dumps(header, separators=(",", ":")).encode()),
        b64url(json.dumps(payload, separators=(",", ":")).encode()),
    ]
    message = ".".join(parts)
    return message + "." + sign(message)

验证通过重新计算签名并将其与令牌中的签名进行比较来进行。只有知道秘密的人才能产生匹配的秘密：

def verify_token(token, now):
    header, payload, signature = token.split(".")
    expected = sign(header + "." + payload)
    if not hmac.compare_digest(signature, expected):
        raise ValueError("bad signature")
    claims = json.loads(b64url_decode(payload))
    if claims["exp"] < now:
        raise ValueError("token expired")
    return claims

有效令牌按预期返回其声明。使用compare_digest是因为它以恒定时间运行，这避免了由于时间差异而泄漏信息。

尝试篡改它

假设攻击者解码有效负载，将 "role":"user" 更改为 "role":"admin"，再次对其进行编码并保留旧签名。我们尝试了这个以及其他两种攻击：

最后一次尝试针对的是一个真正的历史弱点。一些库曾经信任令牌自己的标头，因此攻击者可以简单地声明不需要签名。我们的代码总是使用一种固定的算法，这就是它被拒绝的原因。在真实的库中，始终指定您接受的算法。

已签名，未加密

这是关于 JWT 最容易被误解的一点。我们的伪造令牌被拒绝，但其内容仍然完全可读：

{"sub":"42","role":"admin","iat":1793500000,"exp":1793500900}

Base64URL 是一种编码，而不是加密，任何人都可以在没有密钥的情况下逆向它。签名可以阻止人们更改数据，但不能阻止读取数据。因此，切勿将密码、卡号或私人个人数据放入 JWT 有效负载中。如果必须隐藏内容，请使用加密令牌 (JWE)，或者仅将数据保留在服务器上。

HS256 与 RS256

通过非对称签名，其他服务可以在无法铸造自己的令牌的情况下验证令牌，这限制了一旦受到威胁所造成的损失。

JWT 与会话

JWT 通常被视为会话的现代替代品。实际上，每种方法都需要权衡：

对于传统的服务器渲染网站，会话 cookie 通常更简单、更安全。 JWT 对于多个服务或移动客户端使用的 API 往往更有意义。

在浏览器中存储令牌的位置

许多安全指南都支持 HttpOnly、Secure、SameSite Web 应用程序的 cookie。无论您选择哪种，请始终使用 HTTPS。要从 JavaScript 发送令牌，请参阅我们的 JavaScript Fetch API 教程。

刷新令牌

短暂的有效期限制了令牌被盗造成的损害，但没有人愿意每 15 分钟登录一次。通常的解决方案使用两个令牌：

• 访问令牌： 短暂的，例如几分钟，并随每个 API 请求一起发送。
• 刷新令牌：寿命更长，存储更仔细，仅用于获取新的访问令牌。

服务器会跟踪刷新令牌，因此可以撤销它们，从而为您提供实用的注销。每次使用时轮换它们还可以帮助您检测盗窃行为，因为被盗的旧令牌会被重放。

常见的安全错误

• 解码而不验证。读取有效负载并不使其值得信赖。始终检查签名。
• 接受任何算法。设置允许的算法的明确列表。
• 使用弱秘密。短秘密可以离线破解。使用长随机值，并使其不受源代码控制。
• 跳过过期。没有exp的令牌如果被盗可以永远有效。
• 不检查iss和aud。否则为一项服务颁发的令牌可能会被另一项服务接受。
• 信任过时的声明。令牌内的角色可能会过时，直到过期。
• 记录令牌。任何阅读您日志的人都可以重复使用它们。
• 不测试失败路径。 添加对过期和修改令牌以及有效令牌的测试。我们的使用 Postman 进行 API 测试 指南可以提供帮助。

最后的话

JWT 是服务器无需查找即可信任的签名数据，不是秘密容器，也不是会话自动升级。使用较短的有效期，使用维护的库验证所有内容，并将私有数据保留在有效负载之外。要亲自查看，请运行一个像我们这样的小脚本，更改令牌的一个字符并观察验证失败。

常见问题

继续学习