2. JWT 基础概念
JWT（JSON Web Token）是目前 SaaS 架构中最主流的无状态鉴权协议。理解 JWT 的本质、结构及其与 Session 的差异，是掌握 SaaS 鉴权链路的第一步。
2.1 JWT 是什么
JWT 是一种基于 JSON 格式的开放标准（RFC 7519），用于在各方之间安全地传输声明（Claims）。它通常被用于身份认证和信息交换场景。JWT 的核心特点是：自包含——令牌本身携带了所有必要的用户信息和元数据，服务端无需查询数据库即可完成验证。
核心定义：JWT 是一个经过数字签名的 JSON 对象，可以在不安全的网络环境中安全传递，且服务端无需维护会话状态。
JWT 在 SaaS 鉴权链路中的典型作用：
- 身份认证：用户登录成功后，服务端签发 JWT，客户端后续请求携带该令牌。
- 权限声明：JWT 的 Payload 中包含角色、权限范围等信息，服务端直接解析即可完成鉴权。
- 无状态扩展：由于不依赖服务端存储，SaaS 应用可以轻松水平扩展，无需共享 Session 存储。
2.2 JWT 的组成结构
一个完整的 JWT 由三个部分组成，以点号（.）分隔：Header.Payload.Signature。下面通过一张结构图直观展示其组成。
Header（头部）
Header 通常包含两个字段：令牌类型（typ）和签名算法（alg）。示例：
{
"alg": "HS256",
"typ": "JWT"
}Payload（载荷）
Payload 是 JWT 的核心数据部分，包含声明（Claims）。声明分为三类：
| 声明类型 | 说明 | 示例 |
|---|---|---|
| 注册声明（Registered） | 预定义的标准字段 | iss（签发者）、exp（过期时间）、sub（主题） |
| 公共声明（Public） | 自定义字段，需避免冲突 | role（角色）、tenant_id（租户ID） |
| 私有声明（Private） | 双方约定的自定义数据 | user_permissions（权限列表） |
{
"sub": "1234567890",
"name": "张三",
"role": "admin",
"tenant_id": "t-001",
"exp": 1718000000
}Signature（签名）
签名是对 Header 和 Payload 的完整性保护。生成过程：
HMACSHA256(
base64UrlEncode(header) + "." + base64UrlEncode(payload),
secret_key
)服务端使用相同的密钥验证签名，确保令牌未被篡改。
2.3 JWT 与 Session 的区别
Session 是传统的服务端有状态鉴权方案，JWT 是无状态鉴权方案。两者在 SaaS 架构中的适用场景差异显著。
以下是 Session 与 JWT 在 SaaS 场景下的详细对比：
| 对比维度 | Session 鉴权 | JWT 鉴权 |
|---|---|---|
| 状态存储 | 服务端存储（内存/Redis） | 客户端存储（LocalStorage/Cookie） |
| 扩展性 | 需要共享 Session 存储，扩展复杂 | 无状态，服务端可任意水平扩展 |
| 跨域支持 | 受 Cookie 同源策略限制 | 通过 Authorization 头，天然支持跨域 |
| 主动失效 | 服务端可随时删除 Session | 无法主动撤销，需额外黑名单机制 |
| 性能开销 | 每次请求查询存储，有 I/O 开销 | 仅验证签名，计算开销低 |
| 适用场景 | 传统单体应用、内网系统 | SaaS 多租户、微服务、移动端 |
SaaS 架构建议：对于多租户 SaaS 应用，JWT 是更优选择。它天然支持无状态扩展，且 Payload 中可直接携带
tenant_id 和 role，服务端无需查询数据库即可完成租户隔离和权限校验。
注意：JWT 的 Payload 仅经过 Base64Url 编码，并未加密。敏感信息（如密码、信用卡号）不应直接放入 Payload。如需加密，应使用 JWE（JSON Web Encryption）标准。