1. JWT 基础概念
JWT（JSON Web Token）是一种基于 JSON 的开放标准（RFC 7519），用于在各方之间以紧凑、自包含的方式安全传输信息。在异步任务与微服务架构中，JWT 常作为身份认证与权限校验的核心凭证。
1.1 什么是 JWT
JWT 本质上是一个经过数字签名的 JSON 对象，由三部分拼接而成。它可以在用户与服务器之间、或服务与服务之间传递声明（Claims），且签名保证了数据在传输过程中未被篡改。
核心特性：
- 自包含：令牌本身携带用户身份、权限、过期时间等信息，无需查询数据库。
- 紧凑：体积小，适合 URL、HTTP Header 或 Cookie 传输。
- 防篡改：通过 HMAC 或 RSA/ECDSA 签名保证完整性。
1.2 JWT 的结构
一个 JWT 由 Header、Payload、Signature 三部分组成，以点号 . 分隔，格式为：xxxxx.yyyyy.zzzzz。
| 部分 | 说明 | 示例（Base64 解码后） |
|---|---|---|
| Header | 令牌类型与签名算法 | {"alg":"HS256","typ":"JWT"} |
| Payload | 声明（Claims），包含用户数据与元信息 | {"sub":"123","name":"张三","iat":1718000000} |
| Signature | 对前两部分签名，防止篡改 | HMACSHA256(base64UrlEncode(header) + "." + base64UrlEncode(payload), secret) |
注意：Payload 中的信息是 Base64Url 编码，并非加密。敏感数据（如密码）不应放入 JWT 的 Payload 中。
1.3 JWT 结构示意图
1.4 JWT 与 Session 的区别
在 Web 认证场景中，JWT 与传统的 Session 方案有本质差异。下表从多个维度进行对比：
| 对比维度 | Session 认证 | JWT 认证 |
|---|---|---|
| 存储位置 | 服务端内存/Redis，客户端仅存 Session ID | 客户端持有完整令牌，服务端无状态 |
| 扩展性 | 需要共享 Session 存储（如 Redis 集群） | 天然支持水平扩展，无需共享存储 |
| 跨域支持 | 受限于 Cookie 同源策略，配置复杂 | 通过 HTTP Header 传输，天然支持跨域 |
| 安全性 | Session ID 泄露风险，需配合 CSRF 防护 | 令牌泄露风险，需配合 HTTPS 与短有效期 |
| 吊销机制 | 服务端直接删除 Session 即可 | 需维护黑名单或缩短有效期，吊销成本高 |
| 适用场景 | 传统 Web 应用、服务端渲染页面 | RESTful API、微服务、移动端、异步任务 |
1.5 异步任务场景下的选择
在异步任务与权限验证场景中，JWT 相比 Session 具有明显优势：
- 无状态传递：任务队列中的 Worker 节点无需访问共享 Session 存储，直接解析 JWT 即可获取用户身份与权限。
- 权限自包含：可将角色、资源权限等声明编码在 JWT 中，Worker 节点独立完成校验。
- 减少数据库查询：每次任务处理无需回查用户表或权限表，降低延迟与数据库压力。
安全提醒：在异步任务中使用 JWT 时，务必设置合理的过期时间（如 15-30 分钟），并配合刷新令牌机制。对于长时间运行的任务，应考虑使用短期令牌 + 任务级别的权限校验，避免令牌过期导致任务失败。