JWT 结构详解：JSON Web Token 是如何保证数据安全与防篡改的？

JsonTool
订阅
充电
|

JSON Web Token（JWT）几乎成了现代 Web 身份验证的标配。不论是前后端分离的项目，还是微服务架构，JWT 都能在无状态的前提下，把用户身份安全地传递给服务端。但很多人只停留在“JWT 就是三段字符串拼起来”的印象，背后的安全机制和校验逻辑却容易忽略。

今天我们就把 JWT 拆开来，看看它到底是怎么保证“数据可信”的。

1. JWT 的三段式结构

一个典型的 JWT 看起来是这样的：

1
xxxxx.yyyyy.zzzzz

由三部分拼接而成：

  1. Header（头部）
    描述 JWT 的元信息，比如使用的签名算法。
    示例：

    1
    2
    3
    4
    {
      "alg": "HS256",
      "typ": "JWT"
    }
    • alg 指定签名算法，如 HS256（HMAC-SHA256）、RS256（RSA-SHA256）。
    • typ 通常就是 "JWT"。

  2. Payload（载荷）
    存放业务相关的数据，通常是用户身份、权限、过期时间等。
    示例：

    1
    2
    3
    4
    5
    6
    {
      "sub": "1234567890",
      "name": "Alice",
      "admin": true,
      "exp": 1724832000
    }
    • sub 表示用户 ID。
    • exp 是过期时间戳（Unix 时间）。
      ⚠️ 注意：Payload 里存放的数据并没有加密，只是 Base64URL 编码，任何人都能解码看到。

  3. Signature（签名）
    保证 Header 和 Payload 未被篡改。
    签名的生成公式：

    1
    2
    3
    4
    HMACSHA256(
      base64UrlEncode(header) + "." + base64UrlEncode(payload),
      secret
    )

    如果是非对称加密（如 RS256），会用私钥签名，公钥验证。

2. 组装过程：怎么拼出一个 JWT

  1. 准备 Header 与 Payload：写好 JSON。

  2. Base64URL 编码：把 Header、Payload 分别转成字符串，再用 Base64URL 编码。

    • Base64URL 与普通 Base64 不同，它去掉了 + / =，换成了更适合 URL 的字符。

  3. 计算签名：

    • 对称算法（HS256）：用服务端和客户端都知道的 secret 做 HMAC。
    • 非对称算法（RS256）：用私钥生成签名。

  4. 拼接：

    1
    jwt = header + "." + payload + "." + signature

最终你得到的 JWT，就是一个字符串，既能放在 HTTP Header (Authorization: Bearer xxx) 里，也能放在 Cookie、URL 参数里。

3. 验证过程：服务端如何识别真伪

当客户端带着 JWT 来请求时，服务端会：

  1. 拆分 JWT：按 . 分成三段。
  2. 解码 Header & Payload：得到算法、数据。
  3. 检查过期时间：如果 exp 已过期，直接拒绝。
  4. 重新计算签名：
    • 把收到的 Header、Payload 按同样方式拼接。
    • 用事先约定的 secret 或公钥重新计算签名。
  5. 比对签名：如果计算结果和 JWT 里的 Signature 一致，就说明数据没被改过。

换句话说，JWT 的安全性并不是靠“Payload 不可读”，而是靠“签名不可伪造”。

4. 安全机制与常见误区

JWT 的安全点

  • 不可篡改：攻击者可以改 Payload，但 Signature 一定对不上。
  • 灵活的算法：支持对称/非对称签名，适应不同应用场景。
  • 无状态验证：服务端只要保存密钥或公钥，就能验证 JWT，无需存储会话。

⚠常见误区

  1. 误以为 Payload 加密了
    实际上只是 Base64URL 编码，任何人都能解码。不要在 Payload 里放敏感数据（如明文密码）。
  2. 密钥管理不当
    • HS256 模式下，secret 一旦泄露，任何人都能伪造 JWT。
    • RS256 模式要妥善保管私钥，只暴露公钥。
  3. 忽略过期时间
    不设置 exp，JWT 就会无限期有效。若用户被禁用，JWT 仍可能继续生效，带来风险。
  4. 算法降级攻击
    曾经有攻击手法：把 Header 改成 "alg": "none"，如果服务端验证逻辑写得不严谨，就可能直接放行。所以实现时一定要固定允许的算法。

5. 小结

JWT 的本质就是：

  • Header：告诉你怎么验签。
  • Payload：告诉你用户是谁、什么时候过期。
  • Signature：保证上面两段没被人改过。

理解了这三步，你就能在项目里更安心地用 JWT。真正要注意的点，不在“怎么生成字符串”，而在密钥管理、过期控制、算法选择这些环节。