JWT 是无状态的 - 但真实应用不是

为什么现代系统采用混合有状态认证（以 Facebook 为例）

多年来，JSON Web 令牌（JWT）一直被宣传为身份验证的终极解决方案。其优势在于快速响应、可扩展性强，且无需服务器端会话管理。

然而，观察 Facebook、Google、Netflix 或银行应用等实际生产系统时会发现：

• 用户可保持登录状态数月之久
• 令牌能够被即时撤销
• 可远程登出已泄露的设备
• 离线访问功能依然可用
• 可疑会话会被立即终止

纯 JWT 方案无法安全实现以上所有功能。

因此，现代系统普遍采用混合有状态认证模型。

以下将详细解析这一机制。

标准 JWT 包含以下要素：

• 用户 ID
• 角色/声明信息
• 过期时间
• 数字签名

令牌签发后，服务器端不存储任何状态信息。

验证流程：

客户端 → 提交 JWT
服务器 → 验证签名有效性及过期时间
→ 授予访问权限

核心优势

• 无需会话存储开销
• 具备水平扩展能力
• 极低的响应延迟

但存在关键缺陷：
JWT 签发后服务器无法主动撤销。若令牌泄露，在有效期内将始终可用。

这构成了严重的安全隐患。

无状态令牌缺乏上下文感知能力。
无法判断对应会话是否仍处于活跃状态。

该模型融合了两大要素：

JWT 负责高效授权验证
服务器端会话实现状态控制

这也是 Facebook、Google 及主流身份提供商采用的实现方案。

第一步 — 登录认证

服务器端创建：

• 短期有效的签名 JWT
• 数据库/Redis 中的会话数据记录：

SessionId
UserId
DeviceId
Status = Active
LastSeen

JWT 包含内容：

sub = userId
sid = sessionId
exp = 15 分钟

第二步 — API 请求处理

客户端 → 提交 JWT
服务器端 →
  1. 验证签名合法性
  2. 检查令牌有效期
  3. 查询会话存储获取 sessionId (sid)
  4. 确认会话状态为 Active
→ 通过访问授权

至此，服务器端实现了对令牌的完全控制。

第三步 — 登出或撤销操作

服务器更新会话状态：

Session.Status = Revoked

此后所有使用该 JWT 的请求都将被拒绝——无论令牌是否在有效期内。

会话查询操作通过以下组件实现：

• Redis 缓存
• 内存缓存系统
• 分布式缓存集群

查询延迟通常控制在 2ms 以内。

相较于数据库查询及网络传输开销，此项损耗可忽略不计。

安全性优先于微观优化。

应用系统采用双令牌策略：

• 短期访问令牌（JWT）
• 长期刷新令牌（服务器端有状态）

访问令牌过期时的更新流程：

客户端 → 提交刷新令牌
服务器 → 验证会话状态
→ 签发新 JWT

通过此机制，Facebook 等平台可长期维持用户登录状态。

JWT 本质是授权格式规范，而非完整的身份验证策略。

生产级系统必须能够准确回答：

"当前会话是否仍然有效？"

唯有混合有状态模型能安全实现这一目标。

这正是 Facebook、Google 及企业级系统不单独依赖无状态 JWT 的根本原因。

若为生产环境设计认证体系，
纯无状态方案并不足够。

安全性本质上依赖于状态管理。