JWT认证授权契约接口设计与契约测试 - 第1节
1.1 什么是 JWT
JWT（JSON Web Token）是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间以紧凑、自包含的方式安全地传输信息。JWT 通常被用于身份认证和信息交换场景，其核心特点是：令牌本身即包含所有必要的用户信息，服务端无需维护会话状态。
核心特性：
- 紧凑（Compact）：体积小，可通过 URL、POST 参数或 HTTP Header 快速传输。
- 自包含（Self-contained）：载荷中直接携带用户身份、权限、过期时间等声明，减少数据库查询。
- 防篡改（Tamper-proof）：通过签名（HMAC 或 RSA/ECDSA）保证内容在传输过程中未被修改。
JWT 的结构
一个 JWT 由三部分组成，以点号（.）分隔：
Header.Payload.Signature| 部分 | 说明 | 示例（Base64 解码后） |
|---|---|---|
| Header | 令牌类型与签名算法 | {"alg":"HS256","typ":"JWT"} |
| Payload | 声明（Claims），包含用户数据与元数据 | {"sub":"1234567890","name":"张三","iat":1516239022} |
| Signature | 对前两部分签名，防止篡改 | 由 Header 指定算法生成 |
注意：Payload 仅经过 Base64 编码，并非加密。敏感信息（如密码）不应直接放入 JWT，必须配合 HTTPS 传输。
1.2 JWT 与 Session/Cookie 的区别
传统的 Session-Cookie 认证与 JWT 认证在状态管理、扩展性、跨域支持等方面存在本质差异。下表从多个维度进行对比：
| 对比维度 | Session / Cookie | JWT |
|---|---|---|
| 状态存储 | 服务端存储 Session，客户端存 Cookie（Session ID） | 无状态，令牌自包含用户信息 |
| 扩展性 | 需要共享 Session（如 Redis）或粘性会话 | 天然支持水平扩展，任何服务节点均可验证 |
| 跨域支持 | 受同源策略限制，跨域需额外配置（CORS + Credentials） | 通过 HTTP Header 传递，跨域友好 |
| 安全性 | 依赖 Cookie 的 HttpOnly/Secure 属性，防 XSS 较好 | 防篡改性强，但需防范 XSS 导致令牌泄露 |
| 性能 | 每次请求需查询 Session 存储 | 服务端只需验证签名，无需查库 |
| 移动端适配 | Cookie 在原生 App 中处理不便 | 原生 App 可轻松存储和发送 Token |
选型建议：传统 Web 应用（服务端渲染）可继续使用 Session-Cookie；API 服务、微服务架构、移动端后端、单页应用（SPA）优先选择 JWT。
1.3 JWT 的典型应用场景
JWT 在以下场景中具有显著优势，已成为现代 API 认证的主流方案：
- 单点登录（SSO）：JWT 自包含用户身份，多个系统共享同一令牌即可实现跨系统认证，无需重复登录。
- 移动端 API 认证：原生 App 无 Cookie 概念，JWT 可通过 HTTP Header 轻松传递，适配 iOS/Android。
- 微服务间通信：服务 A 调用服务 B 时，携带 JWT 传递调用者身份与权限，无需中心化认证服务。
- 无状态 RESTful API：服务端不保存会话，JWT 签名验证即可完成认证，便于水平扩展。
- 信息交换：JWT 可携带结构化数据（如用户角色、部门），接收方验证签名后直接使用。
实战建议：JWT 适合短期令牌（如 15 分钟），配合 Refresh Token 实现安全续期。避免在 JWT 中存储敏感数据，始终使用 HTTPS 传输。