1. JWT 基础：结构、工作原理与 Session 对比
JSON Web Token（JWT）是目前分布式系统中最主流的无状态认证令牌格式。理解 JWT 的底层结构、签发验签流程以及与 Session 的差异，是构建安全缓存验签闭环的第一步。
1.1 JWT 结构：三段式令牌
一个标准 JWT 由三个 Base64URL 编码的片段组成，以点号 . 分隔：
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWUsImlhdCI6MTUxNjIzOTAyMn0.
POstGetfAytaZS82wHcjoTyoqhMyxXiWdR7Nn7A29DNSl0EiXLdwJ6xC6AfgZWF1bOsS_TuYI3OG85AmiExREkrS6tDfTQ2B3WXlrrPpF3V1eSfA0h0o7EoGfv2lLqLpG7lF2gH6s6xGqX8G6r1g3Y9z3wX5z7y8b9c0d1e2f3g4h5i6j7k8l9m0n1o2p3q4r5s6t7u8v9w0x1y2z3| 片段 | 名称 | 内容说明 | 是否加密 |
|---|---|---|---|
| 第一部分 | Header | 签名算法（如 RS256、HS256）和令牌类型（JWT） | 仅 Base64 编码，明文可读 |
| 第二部分 | Payload | 声明（Claims）：用户标识、角色、过期时间等 | 仅 Base64 编码，明文可读 |
| 第三部分 | Signature | 对前两部分的签名，用于防篡改验证 | 由密钥/私钥生成，不可伪造 |
关键认知：Payload 是明文编码而非加密。任何能解码 Base64URL 的人都可以读取 Payload 内容。JWT 的安全性依赖 Signature 防篡改，而非 Payload 的机密性。敏感信息（如密码、身份证号）绝不可放入 Payload。
1.2 JWT 工作原理：签发与验签流程
JWT 的工作流程分为签发（Issuance）和验签（Verification）两个阶段，核心是服务端不保存会话状态。
无状态核心：服务端只持有密钥/公钥，不存储 JWT 本身。每次请求携带 JWT，服务端独立完成验签，无需查询数据库或缓存。
1.3 JWT 与 Session 对比
Session 认证是传统的服务端有状态方案，JWT 是分布式架构下的无状态替代方案。两者在存储、扩展性、安全性方面有本质差异。
| 对比维度 | Session 认证 | JWT 认证 |
|---|---|---|
| 状态存储 | 服务端内存/Redis，有状态 | 客户端令牌，无状态 |
| 扩展性 | 需共享 Session 存储（如 Redis 集群），水平扩展复杂 | 服务端无共享状态，天然支持水平扩展 |
| 跨域/跨服务 | 需配置跨域 Cookie 或 Session 同步，实现复杂 | 令牌自包含，跨服务传递简单 |
| 吊销能力 | 服务端直接删除 Session，实时生效 | 需配合黑名单/短过期时间，吊销成本高 |
| 令牌体积 | 仅 Session ID（短字符串） | 包含完整 Payload，体积较大 |
| 安全风险 | CSRF 攻击风险较高，需 Token 防护 | XSS 窃取令牌风险较高，需 HttpOnly 等防护 |
选型建议：单体应用或中小型系统优先考虑 Session + Redis，吊销方便且实现简单。微服务架构、移动端、跨域场景优先选择 JWT。但 JWT 并非万能——令牌一旦签发，在过期前无法主动失效，必须配合短过期时间（如 15 分钟）和 Refresh Token 机制来降低风险。
1.4 JWT 与 Session 架构对比图
下图从架构层面直观展示 Session 认证与 JWT 认证在服务端状态管理上的核心差异。
1.5 核心要点总结
- JWT 三段结构：Header（算法声明）、Payload（用户声明）、Signature（防篡改签名）。Payload 是明文，不可存放敏感数据。
- 无状态认证：服务端不保存 JWT，每次请求独立验签，天然支持水平扩展和微服务架构。
- Session vs JWT：Session 有状态、吊销方便、适合单体；JWT 无状态、跨域友好、吊销困难。选型需结合业务场景。
- 安全基线：JWT 必须使用强签名算法（推荐 RS256 或 ES256），设置合理的过期时间（如 15 分钟），配合 Refresh Token 实现安全续期。