4. JWT 与 Token 机制：Token 的概念、JWT 作为 Token 的优势、无状态认证原理
4.1 什么是 Token？
Token（令牌）是一个代表用户身份与权限的凭证字符串。在传统的 Session 认证中，服务器需要保存用户的登录状态；而 Token 认证则将用户信息编码进一个自包含的字符串中，服务器无需存储会话数据，只需验证 Token 的合法性即可。
核心思想：Token 是“你拥有它，你就是它”的凭证。服务器信任 Token 的签名，而不是依赖数据库中的会话记录。
4.2 JWT 作为 Token 的优势
JWT（JSON Web Token）是目前最流行的 Token 实现方案。相比随机字符串 Token，JWT 具有以下显著优势：
| 对比维度 | 随机字符串 Token | JWT Token |
|---|---|---|
| 数据结构 | 无结构，仅凭唯一标识 | 结构化，包含 Header、Payload、Signature |
| 信息承载 | 需查数据库获取用户信息 | 自包含用户 ID、角色、过期时间等 |
| 验证方式 | 需查数据库或缓存 | 本地签名验证，无需远程查询 |
| 扩展性 | 水平扩展需共享 Session 存储 | 天然支持分布式，无需共享存储 |
| 防篡改 | 依赖存储安全 | 依赖签名算法（HMAC/RSA/ECDSA） |
关键优势总结：JWT 将“查询”变为“计算”，将“存储”变为“签名”，从而实现了真正的无状态认证。
4.3 JWT 的结构解析
一个 JWT 由三个 Base64URL 编码的部分组成，以点号（.）分隔：
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c- Header（头部）：声明类型（typ）和签名算法（alg），如 HMAC SHA256。
- Payload（载荷）：存放声明（claims），如用户 ID（sub）、角色（role）、过期时间（exp）。
- Signature（签名）：对前两部分进行签名，防止数据被篡改。
4.4 无状态认证原理
无状态认证的核心是：服务器不保存任何会话信息。每次请求都携带 JWT，服务器通过验证签名来确认身份。下图展示了完整的认证流程：
4.5 无状态 vs 有状态：核心差异
| 特性 | Session（有状态） | JWT（无状态） |
|---|---|---|
| 存储位置 | 服务器内存/数据库/Redis | 客户端（浏览器/App） |
| 扩展方式 | 需共享 Session 存储（如 Redis 集群） | 任意服务器独立验证，无需共享 |
| 注销即时性 | 立即删除 Session 即可 | 需配合黑名单或短有效期 |
| 网络开销 | 仅传输 Session ID（短字符串） | 传输完整 JWT（较长，约 200-500 字节） |
| 适用场景 | 传统单体应用、内网系统 | 微服务、分布式系统、移动端、单点登录 |
注意：无状态并非万能。JWT 一旦签发，在过期前无法主动失效。对于需要即时注销的场景（如用户修改密码、管理员封禁账号），需要配合 Token 黑名单或短有效期 + 刷新 Token 机制。
4.6 JWT 作为 Token 的典型应用场景
- 单点登录（SSO）：JWT 可以在多个服务间传递用户身份，实现一次登录、全网通行。
- 移动端 API 认证：移动端没有 Cookie 概念，JWT 通过 Authorization Header 携带，天然适配。
- 微服务网关认证：网关验证 JWT 后，将用户信息透传给下游服务，下游无需再次验证。
- 第三方 API 授权：JWT 可作为 API 密钥，携带权限范围（scope），实现细粒度访问控制。
本章小结：JWT 通过自包含的结构化数据和签名机制，将认证从“存储查询”转变为“计算验证”，实现了真正的无状态认证。这是现代分布式系统架构中权限验证的基础能力。