JWT 会话令牌实现：有状态与无状态
JSON Web Tokens (JWT) 已成为在各方之间以 JSON 对象形式安全传输信息的行业标准。在会话管理方面，开发者经常面临一个关键的架构决策：实现应该是无状态 (Stateless) 还是有状态 (Stateful)？
这两种方法各有千秋，选择哪一种完全取决于应用的规模、安全要求和基础设施。
1. 无状态 JWT 实现
在纯无状态实现中，所有会话数据（用户 ID、角色、过期时间）都直接存储在 JWT 内部。服务器不需要在数据库或缓存中存储任何会话信息。
工作原理：
- 用户登录。
- 服务器生成一个包含用户详情的 JWT，并使用密钥对其进行签名。
- 服务器将 JWT 发送给客户端。
- 对于后续的每个请求，客户端都会发送该 JWT。
- 服务器验证签名并信任其中的数据，无需查询数据库。
优点：
- 可扩展性： 由于服务器不需要查找会话数据，因此更容易在多个服务器之间进行水平扩展。
- 性能： 减少了每个请求的数据库/缓存延迟。
- 去中心化： 非常适合微服务架构，不同的服务可以独立验证令牌。
缺点：
- 撤销问题： 令牌一旦发行，在过期前一直有效。如果不引入某种状态，很难在过期前撤销特定令牌（例如，如果用户注销或被封号）。
- 令牌大小： 在 JWT 中存储过多数据会导致头部过大，增加每个 HTTP 请求的开销。
2. 有状态 JWT 实现
有状态实现结合了 JWT 的便携性和传统会话的可控性。在这种模型中， JWT 通常包含一个唯一的会话 ID，而服务器在数据存储（如 Redis 或 SQL 数据库）中维护活跃会话的记录。
工作原理：
- 用户登录。
- 服务器在数据库中创建会话记录，并生成包含会话 ID 的 JWT。
- 服务器将 JWT 发送给客户端。
- 对于每个请求，客户端都会发送该 JWT。
- 服务器验证签名，并检查数据库/缓存以确保会话仍然有效/活跃。
优点：
- 即时撤销： 您可以通过从数据库中删除会话来立即使其失效。
- 更好的控制： 易于实现“从所有设备注销”或监控活跃用户数等功能。
- 安全性： 如果令牌被盗，可以立即将其列入黑名单。
缺点：
- 可扩展性降低： 每个请求都需要查询数据库或缓存，这可能成为瓶颈。
- 基础设施开销： 需要维护高可用的会话存储。
3. 您应该选择哪一个？
| 特性 | 无状态 JWT | 有状态 JWT |
|---|---|---|
| 可扩展性 | 高 | 中 |
| 撤销 | 困难 | 即时 |
| 复杂度 | 低 | 高 |
| 性能 | 更快 | 更慢 |
如果满足以下条件，请使用无状态 JWT： 您正在构建一个高流量的 API，水平扩展是首要任务，并且可以接受短令牌寿命（配合刷新令牌）。
如果满足以下条件，请使用有状态 JWT： 安全至上，且您需要能够立即将用户踢出平台或管理每个用户的多个活跃会话。