JWT接口设计与契约测试 - 第1节
1.1 JWT 是什么
JWT（JSON Web Token） 是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间以安全、紧凑的方式传输声明（Claims）。JWT 通常被用于身份认证和信息交换场景，其核心特点是自包含（Self-contained）——令牌本身携带了用户身份、权限等必要信息，无需依赖服务端会话存储。
一个 JWT 由三部分组成，以点号（.）分隔：
Header.Payload.Signature- Header（头部）：声明令牌类型（typ: JWT）和签名算法（alg: HS256 / RS256 等）。
- Payload（载荷）：携带声明数据，如用户 ID（sub）、过期时间（exp）、发行者（iss）等。载荷中的敏感信息不应明文存放，建议配合 HTTPS 传输。
- Signature（签名）：对 Header 和 Payload 使用指定算法和密钥进行签名，防止数据被篡改。
关键特性：JWT 是 无状态 的，服务端不需要保存会话信息，每次请求客户端携带 JWT，服务端验证签名即可信任令牌内容。
1.2 JWT 与 Session / Cookie 对比
在 Web 应用认证领域，Session-Cookie 模式是传统方案，而 JWT 是近年来广泛采用的替代方案。两者在存储位置、扩展性、跨域支持等方面存在显著差异。
| 对比维度 | Session + Cookie | JWT（Token） |
|---|---|---|
| 存储位置 | 服务端内存/数据库 + 客户端 Cookie | 客户端（浏览器/App），服务端无状态 |
| 扩展性 | 需要共享 Session 存储（Redis/DB），水平扩展复杂 | 天然支持水平扩展，无需共享存储 |
| 跨域支持 | 受 Cookie 同源策略限制，跨域需额外配置 | 通过 HTTP Header 携带，天然支持跨域 |
| 安全性 | 依赖 Cookie 的 HttpOnly/Secure 属性，防 XSS 较好 | 防 CSRF 较好，但需防范 XSS 窃取 Token |
| 性能 | 每次请求需查询 Session，高并发下存在瓶颈 | 服务端仅验证签名，无需查询存储，性能更优 |
| 令牌失效 | 服务端可立即删除 Session 实现强制下线 | JWT 在过期前无法主动失效，需配合黑名单或短有效期 |
选型建议：单体应用或对实时失效要求高的场景，Session-Cookie 依然适用；分布式、微服务、移动端或跨域场景，JWT 是更优选择。
1.3 JWT 的典型应用场景
JWT 凭借其无状态、跨域友好、自包含等特性，在以下场景中得到广泛应用：
- 用户身份认证：用户登录后服务端签发 JWT，客户端在后续请求中携带该令牌，服务端验证签名即可识别用户身份。这是 JWT 最核心的应用。
- 单点登录（SSO）：JWT 天然支持跨域，多个子系统共享同一认证中心签发的 JWT，用户只需登录一次即可访问所有关联系统。
- API 鉴权：微服务架构中，服务间调用使用 JWT 传递调用方身份和权限信息，避免每次调用都查询认证中心。
- 信息交换：JWT 的签名机制确保数据在传输过程中未被篡改，适合在不可信网络环境中交换声明数据。
- 移动端 / 单页应用（SPA）：移动端和 SPA 通常无法使用 Cookie 进行会话管理，JWT 通过 HTTP Header 携带，适配性更好。
注意事项：JWT 的 Payload 仅做 Base64URL 编码，并非加密。敏感信息（如密码、身份证号）不应直接放入 JWT 载荷中，必须配合 HTTPS 传输，必要时对 Payload 进行额外加密。