1. JWT 基础概念：定义、结构与 Session 对比
1.1 JWT 定义
JWT（JSON Web Token） 是一种基于 JSON 的开放标准（RFC 7519），用于在各方之间以紧凑、自包含的方式安全传输信息。JWT 通常用于身份认证和信息交换场景，其核心特点是：
- 紧凑（Compact）：可通过 URL、POST 参数或 HTTP Header 快速传递。
- 自包含（Self-contained）：载荷中直接包含用户信息，减少数据库查询。
- 防篡改（Tamper-proof）：通过签名机制保证数据完整性。
关键认知：JWT 不是加密协议，而是签名协议。签名保证数据未被篡改，但载荷内容默认是 Base64 编码的明文，不应存放密码等敏感信息。
1.2 JWT 结构详解
一个完整的 JWT 由三个部分组成，以点号（.）分隔：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5cHeader（头部）
包含令牌类型和签名算法，通常为 JSON 对象：
{
"alg": "HS256", // 签名算法，常见：HS256、RS256、ES256
"typ": "JWT" // 令牌类型
}Payload（载荷）
存放声明（Claims），分为三类：
| 声明类型 | 说明 | 示例 |
|---|---|---|
| 注册声明 | 预定义标准字段 | iss（签发者）、exp（过期时间）、sub（主题）、iat（签发时间） |
| 公共声明 | 自定义字段，需在 IANA 注册或使用命名空间避免冲突 | "role": "admin" |
| 私有声明 | 双方约定使用的自定义字段 | "user_id": 1001 |
Signature（签名）
由编码后的 Header、Payload 和密钥通过指定算法生成：
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret
)
安全要点：签名是 JWT 防篡改的核心。服务端必须妥善保管密钥（secret/private key），一旦泄露，攻击者可伪造任意令牌。
1.3 JWT 与 Session 对比
JWT 和传统 Session 认证是两种主流的用户状态管理方案，各有优劣。下表从多个维度进行对比：
| 对比维度 | JWT（无状态令牌） | Session（服务端会话） |
|---|---|---|
| 存储位置 | 客户端（浏览器/移动端） | 服务端内存/Redis/数据库 |
| 扩展性 | 天然支持水平扩展，无需共享存储 | 需要集中式 Session 存储（如 Redis） |
| 性能 | 验证时只需计算签名，无需查库 | 每次请求需查询 Session 存储 |
| 安全性 | 签名防篡改，但载荷明文可读 | 数据完全在服务端，客户端仅持有 Session ID |
| 过期控制 | 过期时间写入 exp 声明，无法主动撤销 |
服务端可随时删除 Session 实现强制下线 |
| 跨域支持 | 通过 HTTP Header 传递，天然支持跨域 | 受 Cookie 同源策略限制，跨域需额外配置 |
| 令牌大小 | 较大（包含完整用户信息） | 极小（仅 Session ID 字符串） |
选型建议：微服务架构、移动端、跨域场景优先选择 JWT；传统单体应用、对安全要求极高且需要即时撤销能力的场景，Session 方案更合适。实际生产环境中，两者也常结合使用（如 JWT 做短期令牌 + Redis 做黑名单）。
1.4 核心概念总结
- JWT 定义：基于 JSON 的开放标准，用于安全传输信息，具有紧凑、自包含、防篡改三大特性。
- JWT 结构：Header（算法+类型）+ Payload（声明）+ Signature（签名验证），三者以点号连接。
- 与 Session 对比：JWT 无状态、易扩展、跨域友好，但无法主动撤销；Session 有状态、可即时控制，但依赖服务端存储。