JWT领域建模与架构设计 - 第1节
1.1 JWT 定义与核心原理
JSON Web Token（JWT）是一种基于 JSON 的开放标准（RFC 7519），用于在各方之间以紧凑且自包含的方式安全传输信息。JWT 通常被用于身份认证和信息交换场景，其核心特征在于：令牌本身即包含所有必要的用户信息，服务端无需维护会话状态。
核心公式： JWT = Header（头部） + Payload（载荷） + Signature（签名）
一个典型的 JWT 字符串由三个 Base64URL 编码的部分组成，以点号（.）分隔：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cJWT 三部分结构详解
| 组成部分 | 内容说明 | 示例字段 |
|---|---|---|
| Header（头部） | 声明令牌类型（JWT）和签名算法（如 HMAC SHA256、RSA） | {"alg":"HS256","typ":"JWT"} |
| Payload（载荷） | 存放实际声明（Claims），包括用户身份、过期时间等 | {"sub":"123","name":"John","iat":1516239022} |
| Signature（签名） | 对 Header 和 Payload 进行签名，防止数据被篡改 | 使用密钥对前两部分计算哈希值 |
安全提示： Payload 仅经过 Base64URL 编码，并未加密。敏感信息（如密码、信用卡号）不应直接放入 JWT 载荷中，除非使用 JWE（JSON Web Encryption）进行加密。
1.2 JWT 与 Session/Cookie 对比
在 Web 应用认证领域，JWT 与传统的 Session/Cookie 方案是两种主流选择。理解它们的差异，是构建安全架构的第一步。
| 对比维度 | Session / Cookie | JWT（无状态令牌） |
|---|---|---|
| 状态存储 | 服务端存储 Session，客户端存储 Cookie ID | 令牌自包含，服务端无需存储会话 |
| 扩展性 | 需要共享 Session 存储（如 Redis）或粘性会话 | 天然支持水平扩展，任何服务节点均可验证 |
| 跨域支持 | 受同源策略限制，跨域需额外配置 | 通过 HTTP Header 传递，天然支持跨域 |
| 安全性 | 依赖 Cookie 的 HttpOnly/Secure 属性防 XSS | 签名防篡改，但需防范 XSS 导致令牌泄露 |
| 吊销机制 | 服务端直接删除 Session 即可 | 需维护黑名单或缩短过期时间 |
| 性能开销 | 每次请求需查询 Session 存储 | 仅需计算签名验证，无 I/O 开销 |
架构决策要点： 如果你的应用是单体架构且用户量不大，Session/Cookie 方案实现简单、吊销方便。如果是分布式微服务架构、移动端或单页应用（SPA），JWT 的无状态特性更具优势。但 JWT 的令牌吊销难题需要通过额外机制（如令牌黑名单、短有效期+刷新令牌）来解决。
1.3 JWT 典型应用场景
JWT 因其无状态、跨域友好、自包含等特性，在以下场景中得到了广泛应用：
- 单点登录（SSO）： JWT 作为统一的身份令牌，在多个子系统间传递，用户只需登录一次即可访问所有信任的应用。
- 移动端 API 认证： 移动端无法使用 Cookie 机制，JWT 通过 Authorization Header 传递，天然适配 iOS/Android 客户端。
- 微服务间通信： 服务间调用时，JWT 携带调用方身份和权限信息，接收方直接验证令牌即可，无需调用认证中心。
- 无状态 RESTful API： 每个请求都携带完整的认证信息，服务端无需维护会话，便于水平扩展和负载均衡。
- 信息交换： JWT 的签名机制确保数据在传输过程中未被篡改，可用于安全的身份信息交换。
最佳实践： 在微服务架构中，建议使用 Access Token（短有效期，如 15 分钟） + Refresh Token（长有效期，如 7 天） 的组合方案。Access Token 用于实际资源请求，Refresh Token 用于无感续期，既保证了安全性，又提升了用户体验。