JWT 技术(JSON Web Token) 全解：原理、应用与生产级避坑指南
笔者阅读很多 JWT 技术的博文，发现大多只是讲 “JWT 是什么”，而这篇文章重点介绍它为什么出现、结构细节、以及生产环境中最棘手的“注销与续签”问题。
在前后端分离、微服务架构大行其道的今天，JWT（JSON Web Token）几乎成为了身份认证的代名词。
很多开发者只知道它是一个“长长的字符串”，用来做登录校验，但并不清楚它内部的运作机制，以及它在安全性上的潜在风险。本文将从原理、结构、流程、以及最核心的生产陷阱四个维度进行详细拆解。
一、为什么需要 JWT？（Session vs Token）
在 JWT 出现之前，我们主要使用 Session + Cookie 的方式。
1.传统Session的认证痛点
- 服务端有状态：服务端需要保存 Session 数据（内存或Redis）。
- 扩展性差：集群环境下，必须做 Session 共享（如存入Redis），否则用户请求落到不同服务器会掉线。
- 移动端支持差：原生 App 对 Cookie 的支持不如浏览器友好。
- CSRF 风险：基于 Cookie 自动发送的特性，容易遭受跨站请求伪造攻击。
2.JWT（JSON Web Token）认证优势
- 服务端无状态：服务器不保存任何会话数据，Token本身包含了用户信息和有效期。
- 扩展性强：服务器拿到 Token 只要“解密/验签”即可，天然支持分布式、微服务。
- 跨语言/跨端：JSON是通用的，且不依赖 Cookie ，适合 App、小程序、IoT 设备
一句话总结：
Session 是把“通行证”存在服务器，给你个号码；JWT 是把“通行证”直接印发给你，服务器只负责查验真伪。
二、JWT 的结构解剖
一个标准的 JWT 字符串看起来是这样的：
xxxxx.yyyyy.zzzzz
它由 3 部分 组成，中间用 . 分隔：
1. Header（头部）
描述 Token 的元数据，通常包含两部分：
{ "alg": "HS256", // 签名算法，如 HMAC SHA256 或 RSA "typ": "JWT" // 令牌类型 } Base64Url 编码后，构成第一部分。
2. Payload（负载）
这是最核心的部分，存放有效信息（Claims）。包含标准字段和自定义字段：
{ "sub": "1234567890", // 用户ID "name": "John Doe", // 自定义字段 "admin": true, // 自定义字段 "iat": 1516239022, // 签发时间 "exp": 1516242622 // 过期时间 (非常重要) } Base64Url 编码后，构成第二部分。
生产高危警告：
Payload 只是进行了 Base64 编码，并没有加密！ 任何人拿到 Token 都能解码看到 Payload 内容。
绝对不要在 Payload 中放入密码、手机号等敏感信息！
3. Signature（签名）
1）Signature 的本质：消息摘要 + 密钥
Signature 的本质是一个 MAC（Message Authentication Code）：
用密钥对一段消息做不可逆摘要
它同时解决两个问题：
- 完整性（Integrity）：内容有没有被改
- 身份认证（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 后会：
- 拆分 Header.Payload.Signature
- 使用自己的 Secret重新计算一次 Signature
- 对比：
- 一致 → Token 没被改
- 不一致 → Token 被篡改，直接 401
重点结论：
JWT 的安全性完全依赖 Secret 是否泄露
三、标准认证流程
- 登录：用户提交用户名密码。
- 签发：服务端验证通过，生成 JWT（包含用户ID、过期时间等），返回给客户端。
- 存储：客户端收到 JWT，存储在 LocalStorage 或 Cookie 中。
- 请求：客户端再次发起请求时，在 HTTP Header 中携带：Authorization: Bearer <token>
- 验签：服务端拦截请求，解析 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。
流程：
- Access Token 过期，请求返回 401。
- 客户端自动携带 Refresh Token 请求 /refresh 接口。
- 服务端验证 Refresh Token 合法，返回新的 Access Token。
- 如果 Refresh Token 也过期了，强制用户重新登录。
五、JWT vs Session 对比总结
| 维度 | Session | JWT |
|---|---|---|
| 状态存储 | 服务端（内存/Redis） | 客户端（自带数据） |
| 扩展性 | 差（需 Session 共享） | 极好（无状态） |
| 安全性 | 防 CSRF 较麻烦，需防 Session 劫持 | 需防 XSS，签名防篡改 |
| RESTful | 不符合（有状态） | 符合（无状态） |
| 性能 | 需查库/查缓存 | CPU 计算签名（略耗 CPU） |
| 注销 | 容易（服务端删 Session） | 难（需黑名单机制） |
六、安全避坑 Checklist
在生产环境使用 JWT，请务必检查以下几点：
- 必须使用 HTTPS：防止 Token 在传输过程中被中间人窃听。
- 算法安全：验证 Header 中的 alg，防止黑客将算法修改为 None（空算法攻击）。
- 不要存敏感数据：Payload 仅仅是 Base64 编码，谁都能看。
- 密钥保管：Secret 是命根子，绝对不能硬编码在代码里，要放在环境变量或配置中心。
- 存储位置：
- 建议存 HTTPOnly Cookie（防 XSS，但需处理 CSRF）。
- 存 LocalStorage（方便，但容易被 XSS 攻击读取）。
JWT 规范：RFC 7519
以上就是笔者对于 JWT 技术的讲解，如有错误，欢迎指正！
