1.1 JWT 基础概念
JWT（JSON Web Token）是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间以紧凑、自包含的方式安全传输信息。在分布式系统中，JWT 已成为最主流的无状态鉴权方案，它解决了传统 Session 认证在微服务架构下的扩展性瓶颈。
1.1.1 JWT 定义与结构
一个 JWT 由三个 Base64URL 编码的部分组成，以点号（.）分隔：
# JWT 结构示例
eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.
eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiaWF0IjoxNTE2MjM5MDIyfQ.
SflKxwRJSMeKKF2QT4fwpMeJf36POk6yJV_adQssw5c| 组成部分 | 名称 | 内容说明 |
|---|---|---|
| Header | 头部 | 令牌类型（typ）和签名算法（alg），如 HS256、RS256 |
| Payload | 载荷 | 声明（Claims），包含用户身份、过期时间、自定义数据等 |
| Signature | 签名 | 对前两部分进行签名，防止数据被篡改 |
关键特性：JWT 是自包含的——所有用户身份信息和权限声明都编码在令牌本身，服务端无需查询数据库即可完成验证。这是它与传统 Session 认证最本质的区别。
1.1.2 JWT 与传统 Session 认证对比
传统 Session 认证依赖服务端存储会话状态，而 JWT 将状态转移至客户端。以下从多个维度进行对比：
| 对比维度 | 传统 Session 认证 | JWT 认证 |
|---|---|---|
| 状态存储 | 服务端内存/Redis 存储 Session | 客户端存储令牌，服务端无状态 |
| 扩展性 | 需要 Session 共享或集中存储，水平扩展复杂 | 天然支持水平扩展，任何服务节点均可独立验证 |
| 跨域支持 | 受 Cookie 同源策略限制，跨域需额外配置 | 通过 HTTP Header 传输，天然支持跨域 |
| 性能开销 | 每次请求需查询 Session 存储，存在 I/O 延迟 | 仅需本地计算验证签名，无 I/O 开销 |
| 安全性 | Session ID 泄露风险，但数据在服务端 | 令牌包含用户数据，需配合 HTTPS 和短有效期 |
| 主动失效 | 服务端可直接删除 Session | 无法主动失效，需配合黑名单或短有效期 |
实践注意：JWT 并非 Session 的完全替代品，而是适用于不同场景。对于需要服务端主动控制会话（如强制下线、账号封禁）的场景，传统 Session 或 JWT + 黑名单机制更为合适。
1.1.3 JWT 在分布式系统中的优势
在微服务架构和分布式系统中，JWT 的核心优势体现在以下三个方面：
- 无状态验证——每个服务节点独立验证 JWT 签名，无需共享 Session 存储，消除了集中式存储的单点故障和性能瓶颈。
- 去中心化信任——使用非对称签名（RS256/ES256）时，只有签发服务持有私钥，其他服务仅需公钥即可验证，降低了密钥泄露风险。
- 减少网络开销——用户信息直接编码在令牌中，服务间调用无需反复查询用户服务获取权限数据，降低了服务间耦合。
典型场景：在 API 网关统一签发 JWT，下游微服务通过公钥验证令牌并提取用户角色、权限等声明，无需调用认证中心即可完成鉴权决策。
下图展示了 JWT 在分布式系统中的典型鉴权流程：
1.1.4 JWT 的典型应用模式
在分布式系统中，JWT 通常与以下模式配合使用：
- Access Token + Refresh Token 双令牌模式——短有效期（15-30分钟）的 Access Token 用于业务请求，长有效期（7-30天）的 Refresh Token 用于无感续期，兼顾安全性与用户体验。
- 网关统一签发与验证——API 网关作为统一入口，负责 JWT 的签发和初步验证，下游微服务仅需信任网关传递的用户信息。
- 服务间调用传递——微服务间调用时，将 JWT 通过 HTTP Header 传递，下游服务可提取调用方身份进行细粒度权限控制。
最佳实践：在分布式系统中，建议使用非对称算法（RS256 或 ES256）签发 JWT。认证中心持有私钥签发令牌，各微服务仅需配置公钥即可完成验证，避免私钥在多个服务间传播带来的安全风险。