JWT契约校验 - 第1节
1.1 JWT 定义：什么是 JSON Web Token？
JWT（JSON Web Token，RFC 7519） 是一种紧凑的、URL 安全的令牌格式，用于在各方之间以 JSON 对象的形式安全地传输声明（Claims）。JWT 通常被用于身份认证和信息交换场景，其核心特点是：自包含（令牌本身携带用户信息）和 可验证（通过数字签名保证完整性）。
核心公式： JWT = Header（头部）+ Payload（载荷）+ Signature（签名）
一个典型的 JWT 字符串由三个 Base64URL 编码的部分组成，以点号（.）分隔：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c| 组成部分 | 说明 | 示例内容 |
|---|---|---|
| Header（头部） | 声明令牌类型和签名算法 | {"alg":"HS256","typ":"JWT"} |
| Payload（载荷） | 携带声明数据（用户信息、过期时间等） | {"sub":"123","name":"John","iat":1516239022} |
| Signature（签名） | 对前两部分进行签名，防止篡改 | HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) |
💡 关键理解： JWT 的签名机制保证了令牌在传输过程中未被篡改，但 Payload 本身是 Base64URL 编码（非加密），因此 敏感信息不应直接放入 JWT，除非使用 JWE（JSON Web Encryption）进行加密。
1.2 JWT 与 Session / Token 的区别
在 Web 认证领域，Session、Token（泛指） 和 JWT 是三种主流方案。理解它们的差异是正确选型的前提。
| 对比维度 | Session（服务端会话） | Token（不透明令牌） | JWT（自包含令牌） |
|---|---|---|---|
| 存储位置 | 服务端内存/Redis | 服务端数据库/缓存 | 客户端（令牌自身携带数据） |
| 扩展性 | 差（需共享 Session 存储） | 中（需共享令牌校验逻辑） | 好（无状态，任意服务可验证） |
| 信息可见性 | 服务端完全控制 | 服务端完全控制 | Payload 可解码读取（非加密） |
| 防篡改 | 依赖服务端存储 | 依赖服务端存储 | 数字签名保证 |
| 跨域/跨服务 | 困难（Cookie 域限制） | 较易（Header 传递） | 容易（标准 Header 或 URL 参数） |
| 吊销能力 | 强（直接删除 Session） | 强（删除 Token 记录） | 弱（需黑名单或短过期） |
⚠️ 常见误区： 很多人将 JWT 等同于 Token。实际上，JWT 是 Token 的一种 结构化、自包含 的实现方式。传统的 Opaque Token（不透明令牌）只是一个随机字符串，服务端必须查库才能获取用户信息；而 JWT 解码后即可获得用户身份，减少了数据库查询。
1.3 JWT 的典型应用场景
JWT 因其无状态、跨语言、跨域的特性，在以下场景中被广泛采用：
- 单点登录（SSO）： 用户登录一次，JWT 在多个子系统间传递，无需重复认证。
- 前后端分离架构： 前端（SPA/移动端）通过 Authorization Header 携带 JWT，后端无状态验证。
- API 网关认证： 网关统一校验 JWT 签名，将用户身份转发给下游微服务。
- 信息交换： 双方通过 JWT 签名确保数据未被篡改，适用于 OAuth2.0、OpenID Connect 等协议。
- 移动端认证： 避免 Session Cookie 在移动端的不兼容问题，JWT 通过 HTTP Header 传递。
📌 选型建议：
- 单体应用、服务端渲染：Session 方案更简单成熟。
- 微服务架构、跨域认证、移动端：JWT 是更优选择。
- 高安全要求（如金融）：考虑 JWT + 短过期 + Refresh Token 轮换机制。