[测试技术] 深入理解 JSON Web Token (JWT)
*原创内容，未获授权禁止转载、转发、抄袭。
在现代 Web 开发中，身份认证（Authentication）是绕不开的话题。随着微服务架构的流行和前后端分离模式的普及，传统的基于 Session-Cookie 的认证方式逐渐显露出其局限性。
取而代之的，是 JSON Web Token (JWT)。它轻量、无状态、跨语言，成为了目前最流行的跨域认证解决方案。
作为一名开发者，你可能已经在使用 JWT，但你真的理解它的内部原理吗？你知道如何安全地存储它吗？本文将带你从头到尾彻底解析 JWT。
1. 为什么我们需要 JWT？
在讲“是什么”之前，先看“为什么”。
传统的 Session 认证模式
在 Web 1.0 时代，我们通常这样做：
- 用户登录，服务器验证通过。
- 服务器在内存或数据库中创建一个 Session，并记录用户信息。
- 服务器将 Session ID 返回给浏览器，写入 Cookie。
- 之后浏览器的每次请求都会自动带上这个 Cookie。
- 服务器拿着 Cookie 里的 ID 去查 Session，确认用户身份。
这种模式的问题在于：
- 扩展性差（Stateful）： 服务器必须保存状态。如果你的应用做负载均衡（Load Balancer），用户第一次请求到了服务器 A，第二次请求到了服务器 B，服务器 B 没有这个 Session，用户就掉线了（除非做复杂的 Session 同步或使用 Redis 集中存储）。
- CORS（跨域）问题： Cookie 在跨域场景下处理起来非常麻烦。
- CSRF 攻击： 基于 Cookie 的自动发送特性，容易遭受跨站请求伪造攻击。
JWT 的无状态（Stateless）革命
JWT 的核心思想是：服务器不再保存任何 Session 数据。
服务器仅负责生成一个“令牌”（Token），这个令牌里包含了用户是谁、有什么权限、什么时候过期。服务器对这个令牌进行签名（防止篡改），然后发给客户端。客户端自己保存这个令牌，每次请求带上即可。
2. JWT 是什么？长什么样？
根据 RFC 7519 标准，JWT 是一个紧凑的、URL 安全的字符串。它的样子通常是这样的：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9. eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ. SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c仔细观察，你会发现它由三部分组成，中间用点（.）隔开：
- Header（头部）
- Payload（负载）
- Signature（签名）
也就是：Header.Payload.Signature
第一部分：Header
Header 是一个 JSON 对象，描述了 JWT 的元数据，通常包含两部分：令牌类型（即 JWT）和使用的签名算法（如 HMAC SHA256 或 RSA）。
{ "alg": "HS256", "typ": "JWT" }最后将此 JSON 进行 Base64Url 编码，就得到了第一部分。
第二部分：Payload
Payload 也是一个 JSON 对象，用来存放实际需要传递的数据。这些数据被称为 Claims（声明）。
RFC 标准定义了一些由系统保留的声明（建议使用，但不强制）：
- iss (issuer): 签发人
- exp (expiration time): 过期时间
- sub (subject): 主题（通常是用户 ID）
- iat (issued at): 签发时间
你也可以定义私有声明：
{ "sub": "1234567890", "name": "John Doe", "admin": true }注意： Payload 也是经过 Base64Url 编码的，它是明文的！ 任何人拿到 Token 都可以解码看到 Payload 的内容。千万不要在 Payload 中存放密码等敏感信息。
第三部分：Signature
这是最关键的部分，用于验证消息在传递过程中没有被篡改。
生成公式如下：
HMACSHA256( base64UrlEncode(header) + "." + base64UrlEncode(payload), your-256-bit-secret )服务器拿到 Header 和 Payload，用同样的算法和**只有服务器知道的密钥（Secret）**再算一次签名。如果算出来的签名和 Token 里携带的签名一致，说明这个 Token 是合法的，且内容没有被修改过。
3. JWT 的工作流程
- 用户登录：客户端向服务器发送用户名和密码。
- 生成 Token：服务器验证通过后，计算出 JWT（Header + Payload + Signature），返回给客户端。
- 存储 Token：客户端收到 JWT，将其存储在 LocalStorage 或 Cookie 中。
- 验证 Token：服务器拦截请求，提取 Token，验证签名是否正确、是否过期。
- 响应：验证通过，处理业务逻辑并返回数据；验证失败，返回 401 Unauthorized。
请求资源：客户端再次发起请求（如获取订单列表）时，通常会在 HTTP 请求头中携带 Token：
Authorization: Bearer <token>4. JWT vs Session：优缺点深度对比
| 特性 | Session 模式 | JWT 模式 |
| 状态存储 | 服务端（内存/Redis） | 客户端（自身存储） |
| 扩展性 | 较差（需同步 Session） | 极佳（天生支持分布式/微服务） |
| 带宽消耗 | 小（仅传输 Session ID） | 大（Header+Payload 越大 Token 越长） |
| 安全性 | 容易防御 XSS，需防 CSRF | 需防 XSS，天然免疫 CSRF |
| 注销机制 | 容易（服务端删除 Session 即可） | 困难（一旦签发，有效期内很难由服务端强制失效） |
5. 必须掌握的 Security Best Practices（安全最佳实践）
很多 JWT 的安全漏洞并非技术本身的问题，而是使用姿势不对。作为专业开发者，以下几点必须牢记：
1. 永远使用 HTTPS
JWT 也就是一段字符串，如果在 HTTP 明文传输中被拦截，攻击者就可以冒充用户（中间人攻击）。全站 HTTPS 是标配。
2. 签名算法的选择
- HS256 (对称加密)：由于只有一个密钥（Secret），任何拥有该密钥的人都可以签发 Token。适用于单体应用。
- RS256 (非对称加密)：私钥签发，公钥验证。适用于微服务架构（认证中心发 Token，业务服务只验 Token）。
3. Token 存储位置：Cookie 还是 LocalStorage？
这是一个经典的争论。
- LocalStorage:
- 优点：使用方便，前端完全可控。
- 缺点：容易受到 XSS（跨站脚本攻击）。如果黑客注入一段 JS 代码，就能轻松读出 localStorage 里的 Token。
- HttpOnly Cookie:
- 优点：JS 无法读取，免疫 XSS 盗取 Token。
- 缺点：容易受到 CSRF 攻击（需要配合 CSRF Token 防御），且跨域稍微麻烦一点。
专家建议：如果安全性要求极高，建议存储在标记为 httpOnly 和 Secure 的 Cookie 中。
4. 解决“注销难”和“续期”问题
JWT 最大的痛点是：一旦签发，无法撤回。 如果用户修改了密码，或者管理员想封禁某个账号，旧的 Token 在过期前依然有效。
解决方案：
- 黑名单机制：将已注销但未过期的 Token ID 存入 Redis（设置 TTL 与 Token 过期时间一致）。每次验证时查一下 Redis。虽然这牺牲了一点“无状态”的特性，但在安全和性能之间取得了平衡。
- 双 Token 机制（Access Token + Refresh Token）：
- Access Token：有效期短（如 15 分钟），用于请求资源。
- Refresh Token：有效期长（如 7 天），专门用于换取新的 Access Token。
- 当 Access Token 过期，前端用 Refresh Token 去换新的。如果用户注销，服务端只需把 Refresh Token 设为无效，用户手中的 Access Token 最多活 15 分钟。
6. 总结
JWT 是现代 Web 应用架构（特别是前后端分离和微服务）中不可或缺的技术。
何时使用 JWT？
- 微服务架构。
- 移动端应用（App 无法像浏览器那样处理 Cookie）。
- 不需要服务端保存过多状态的场景。
何时不使用 JWT？
- 对安全性要求极高，需要极其严格的 Session 管理（如银行系统，通常还是用 Session）。
- Token 数据量过大，导致 HTTP 请求头过重。
技术没有银弹，只有最适合的方案。希望这篇文章能帮你彻底搞懂 JWT，并在项目中优雅地使用它。
