JWT 全解：原理、应用与生产级避坑指南

Base64Url 编码后，构成第二部分。

生产高危警告： Payload 只是进行了 Base64 编码，并没有加密！ 任何人拿到 Token 都能解码看到 Payload 内容。 绝对不要在 Payload 中放入密码、手机号等敏感信息！

3.Signature（签名）

1）Signature 的本质：消息摘要 + 密钥

Signature 的本质是一个 MAC（Message Authentication Code）：

用密钥对一段消息做不可逆摘要

它同时解决两个问题：

1. 完整性（Integrity）：内容有没有被改
2. 身份认证（Authenticity）：是不是'我'签的

2）签名到底签了什么

以最常见的 HS256（HMAC + SHA256） 为例：

signature = HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), secret )

注意三个重点（面试/实战必考）：

1. 被签名的是 Header + Payload

• 不是只签 Payload
• Header 里包含算法类型 alg
• 改 Header 或 Payload 任意一个字节，签名都会失效

2. 使用的是 对称密钥（Secret）

• 签名 & 验证使用同一个 Secret
• 谁拿到 Secret，谁就可以：
  • 伪造 Token
  • 提权（admin: true）

3. 这是不可逆的

• 无法从 Signature 推导出 Payload
• 也无法从 Payload 推导出 Secret

3）一步一步看签名是如何生成的

假设我们有：

Header

{ "alg": "HS256", "typ": "JWT" }

Base64Url 编码后：

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9

Payload

{ "sub": "1001", "admin": false, "exp": 1700000000 }

Base64Url 编码后：

eyJzdWIiOiIxMDAxIiwiYWRtaW4iOmZhbHNlLCJleHAiOjE3MDAwMDAwMDB9

拼接待签名字符串

eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMDAxIiwiYWRtaW4iOmZhbHNlLCJleHAiOjE3MDAwMDAwMDB9

使用 Secret 做 HMAC

HMACSHA256(data, secret)

得到 Signature：

Xk8Zk0gQZKZP6u9M1KxZPzXqZk8rQ2kR2WZc9F7d2Gs

最终 JWT

Header.Payload.Signature

4）为什么篡改 Payload 一定会失败？

假设黑客做了这件事：

{ "admin": false } ↓ { "admin": true }

恶意攻击者能做到什么？

• 能解码 Payload（Base64 是明文）
• 无法生成新的合法 Signature

因为Secret 不在黑客手里：

HMACSHA256(新 Header + 新 Payload, ???)

服务器验证时做了什么？

服务器收到 Token 后会：

1. 拆分 Header.Payload.Signature
2. 使用自己的 Secret重新计算一次 Signature
3. 对比：
   • 一致 → Token 没被改
   • 不一致 → Token 被篡改，直接 401

重点结论： JWT 的安全性完全依赖 Secret 是否泄露

三、标准认证流程

1. 登录：用户提交用户名密码。
2. 签发：服务端验证通过，生成 JWT（包含用户 ID、过期时间等），返回给客户端。
3. 存储：客户端收到 JWT，存储在 LocalStorage 或 Cookie 中。
4. 请求：客户端再次发起请求时，在 HTTP Header 中携带：Authorization: Bearer
5. 验签：服务端拦截请求，解析 JWT，验证签名是否正确、是否过期。
   • 验证通过：放行，提取 Payload 中的用户 ID 进行业务逻辑。
   • 验证失败：返回 401 Unauthorized。

四、JWT 的致命缺陷与解决方案（生产级）

JWT 虽好，但它有一个核心缺陷：一旦签发，无法撤回（Stateless）。

1. 无法强制登出（Logout 问题）

因为服务端不存状态，用户点击'注销'后，只要 Token 还没过期，如果被黑客截获，依然可以使用。

解决方案：

• 黑名单机制（Blacklist）：注销时将 Token ID ( jti == JWT ID ) 存入 Redis，设置过期时间等于 Token 的剩余有效期。每次校验时查一下 Redis。
  • 缺点：引入了状态，违背了 JWT 无状态初衷（但在生产中是必要的折中）。

2. 续签问题（Refresh Token）

JWT 过期时间设太长不安全，设太短用户体验差（老是需要重新登录）。

最佳实践：双 Token 机制

• Access Token：有效期短（如 15 分钟），用于请求资源。
• Refresh Token：有效期长（如 7 天），仅用于获取新的 Access Token。

流程：

1. Access Token 过期，请求返回 401。
2. 客户端自动携带 Refresh Token 请求 /refresh 接口。
3. 服务端验证 Refresh Token 合法，返回新的 Access Token。
4. 如果 Refresh Token 也过期了，强制用户重新登录。

五、JWT vs Session 对比总结

六、安全避坑 Checklist

在生产环境使用 JWT，请务必检查以下几点：

1. 必须使用 HTTPS：防止 Token 在传输过程中被中间人窃听。
2. 算法安全：验证 Header 中的 alg，防止黑客将算法修改为 None（空算法攻击）。
3. 不要存敏感数据：Payload 仅仅是 Base64 编码，谁都能看。
4. 密钥保管：Secret 是命根子，绝对不能硬编码在代码里，要放在环境变量或配置中心。
5. 存储位置：
   • 建议存 HTTPOnly Cookie（防 XSS，但需处理 CSRF）。
   • 存 LocalStorage（方便，但容易被 XSS 攻击读取）。

JWT 规范：RFC 7519