[!info] related notes

• 所属 MOC: 后端开发 MOC、安全 MOC
• 原子概念: Server-side Session 鉴权, Access Token, Refresh Token, JWT
• 基础关系: Cookie、Session、Token 与 JWT 的关系
• 实现流程: Access Token / Refresh Token 认证实现流程
• 会话生命周期: Active Sessions & Device Management, Credential Change & Session Revocation
• Assurance: Authentication Assurance & Reauthentication Freshness

Stateful、Stateless 与 Hybrid 认证架构

覆盖范围

这篇不讨论密码登录、OAuth Provider 或 MFA，而只讨论：登录成功后，系统如何维护长期登录状态，以及普通 API 请求如何携带和验证凭证。

为什么需要一起理解

认证系统常把四个维度混在一起：

State
→ 登录生命周期由谁保存？

Credential role
→ Access Token / Refresh Token / Session Token 各自做什么？

Credential format
→ JWT 还是 opaque random string？

Transport
→ Cookie 还是 Authorization Header？

只有把这四层拆开，才能正确比较 Session 和 JWT。

方案一：纯 Server-side Session

Client
  │ opaque session token
  ▼
Server
  │ lookup
  ▼
Session Store

每次请求都通过 Session Store 确认登录状态。

特点：

• 服务端掌握实时会话权威；
• logout / revoke 可以立即生效；
• 客户端 Token 只是随机 Session 标识，不需要 JWT；
• 每个请求通常需要共享状态查询。

这类方案特别适合普通 Browser Web App、BFF 或单体/模块化后端，因为实现简单，撤销语义清楚。

方案二：纯 Stateless Access Token

Client
  │ self-contained signed token
  ▼
Resource Server
  │ local verify
  ▼
allow / deny

服务端不保存每次登录对应的实时 Session 状态，通常根据签名、exp、iss、aud、scope 等本地判断。

优点是高频请求无需 Session lookup，适合多服务独立验证。

代价是：一个已签发且未过期的 Token 很难立即单独撤销，用户封禁、权限变化和 logout 可能只能等 Token 过期，除非重新引入 blacklist、version、introspection 等服务端状态。

方案三：Hybrid

Hybrid 把“长期生命周期”和“高频请求验证”分开：

Server-side Session / Grant
        │
        │ issue
        ▼
short-lived Access Token
        │
        │ normal API requests
        ▼
Resource Server local verify

Access Token 过期时：

Refresh Token
      ↓
Authorization Server
      ↓
check Session / Grant / revoke / user state
      ↓
new short-lived Access Token

核心思想是：

高频路径
→ Stateless fast path

低频生命周期控制
→ Stateful authority

因此 Hybrid 可以理解为：长期登录状态有状态，短期 Access Token 无状态。

Access Token 是 Session 的短期投影

一个有用心智模型：

Session / Grant
= 当前长期登录生命周期的 Source of Truth

Access Token
= 某个时刻从这份状态签发出的短期授权快照

如果 Session 在 Access Token 签发后被撤销，而 Resource Server 不查 Session，那么已签发 Access Token 可能继续工作到 exp。

这段时间就是 stale authorization window。短 TTL 的意义是限制这个窗口，而不是实现真正的即时撤销。

Refresh Token 的角色

Refresh Token 是进入长期生命周期控制面的高价值凭证：

Refresh Token
→ validate / rotate
→ check Session / Grant
→ issue new Access Token

因此 Hybrid 架构通常把 Refresh、Logout、Revoke、设备管理等放回 Auth Server，而不是让每个 Resource Server 管理长期 Session。

Authentication 与 Authorization

即使 Access Token 带 role、scope：

Token valid
≠
所有资源操作都已授权

例如是否能修改 Assessment 789，仍可能需要查询当前业务数据判断 ownership、组织关系或资源状态。

所以：

Access Token
→ identity + coarse-grained claims

Policy / Service / DB
→ fine-grained resource authorization

什么时候选哪一种

普通 Browser Web App

优先考虑：

HttpOnly Cookie
→ opaque session token
→ server-side Session

如果每次 Session lookup 的成本并不是系统瓶颈，就没必要为了“使用 JWT”额外引入 Access/Refresh 双 Token、rotation、replay family 和刷新并发控制。

Mobile / Public API / 多 Resource Server / 微服务

Hybrid 往往更有价值：

• Access Token 可以被不同服务本地验证；
• Auth Server 继续掌握长期生命周期；
• Refresh 请求频率远低于普通 API 请求。

需要绝对即时撤销的敏感操作

即使系统整体使用短期 Access Token，也可以对敏感操作强制做额外 Session / User 状态检查，或采用更短的凭证窗口。

不是“哪种更现代”

Session
≠ 旧技术
JWT
≠ 高级版 Session
Hybrid
≠ 所有项目默认答案

真正的决策问题是：

• 是否需要每请求实时撤销？
• 有多少独立 Resource Server？
• 可以接受多长的 stale window？
• Session Store 延迟和可用性成本如何？
• 客户端类型是 Browser、Mobile 还是第三方 API Client？

最短记忆

Stateful Session
→ 每请求回到实时服务端状态

Stateless Token
→ 每请求只验证短期凭证本身

Hybrid
→ 长期生命周期有状态 + 短期访问快路径无状态

JWT 只是其中一种凭证格式，不定义系统属于 Stateful 还是 Stateless。