[!info] related notes

• 所属 MOC: Backend Engineering MOC, 安全 MOC
• 前置关系: Cookie、Session、Token 与 JWT 的关系
• 凭证概念: Access Token, Refresh Token, JWT
• 架构关系: Stateful、Stateless 与 Hybrid 认证架构
• 相关数据库概念: 一对多关系, 外键, 数据库索引
• 凭证变更: Credential Change & Session Revocation
• 会话管理: Active Sessions & Device Management, Authentication Assurance & Reauthentication Freshness

Server-side Session 鉴权

一句话定义

Server-side Session 是由服务端保存长期登录生命周期状态的认证模型。客户端通常只持有一个能够定位或访问该 Session 的凭证，服务端决定这次登录现在是否仍然有效。

Session 是状态，不是某种 Cookie

Session
= server-side login state

Cookie
= browser transport/storage

Session Token
= client credential used to locate Session

所以最经典的纯 Session 方案是：

Browser
  │ HttpOnly Cookie: session=<opaque random token>
  ▼
Server
  │ lookup
  ▼
Session Store

这里完全不需要 JWT。

数据模型

一个用户通常可以有多个活跃 Session：

User 1 ─── N Session

常见字段：

id / session_id
user_id
credential_hash / token_hash
created_at
expires_at
revoked_at
device / user_agent / ip（按需）

Session Store 可以是关系数据库、Redis 或专门的 Auth Store。核心不是存储介质，而是服务器拥有当前生命周期的权威状态。

纯 Session 请求链

request
  ↓
read session credential
  ↓
lookup Session Store
  ↓
Session exists?
not expired?
not revoked?
User allowed?
  ↓
authenticated principal
  ↓
Authorization

这种模式的优势是：

• logout 可以立即生效；
• 可以强制踢下某台设备；
• 可以“退出所有设备”；
• 用户封禁、Session 撤销可以实时阻断后续请求。

代价是每个受保护请求通常需要访问共享 Session 状态。

Logout 语义

退出当前设备
→ revoke/delete current Session

退出所有设备
→ revoke/delete all Sessions for user

如果只是浏览器删除 Cookie，而服务端 Session 仍然有效，那么攻击者手里已泄露的同一个 Session Token 仍可能继续工作。

Session Token 本身可以是 opaque token

最简单的 Session Token 可以只是高熵随机字符串：

random token
→ hash / lookup
→ Session row

它本身不需要携带 user_id、role 或其他业务 claims。

这也是为什么“使用 Token”不等于“使用 Stateless JWT”。纯 Stateful Session 本身就会使用 Token，只不过 Token 只是一个不透明 Session 凭证。

与 Hybrid 架构的关系

Server-side Session 不只用于“每请求都查 Session”的纯 Stateful 模式。

它也可以作为 Hybrid 架构中的长期生命周期 Source of Truth：

Session / Grant
      │
      ├─ issue short-lived Access Token
      └─ bind / validate Refresh Token

普通 API 请求可以只本地验证短期 Access Token，而 Refresh、Logout、Revoke、设备管理再回到这份服务端 Session/Grant 状态。

因此：

Server-side Session
≠ 必然每个请求都查 Session

是否每请求 lookup，是架构选择。

Session 与 User 状态

Session 存在也不意味着账户永远可用。系统可以在创建/刷新 Session 时检查：

• user disabled；
• password reset / security event；
• account deleted；
• tenant membership revoked。

对于要求即时生效的系统，也可以在每请求 Session lookup 时一起检查 User 状态；Hybrid 短期 Access Token 模式则通常接受一个有限的 stale window。

索引与热路径

如果每次请求都按 Session Token 查找：

SELECT ... FROM sessions WHERE token_hash = ?;

对应查找字段应有唯一约束或合适索引。Session Store 延迟会直接进入认证热路径，因此容量、缓存和可用性也属于认证架构的一部分。

安全边界

• Session Token 应具备足够熵，避免可预测；
• 高价值 bearer credential 不应在服务端以可直接复用明文长期保存，常见做法是保存 hash/digest；
• expires_at、revoke 状态都应校验；
• Browser Cookie 场景应考虑 HttpOnly、Secure、SameSite 和 CSRF；
• Authentication 通过后，资源级 Authorization 仍需独立执行。

边界与常见误解

• “Session = Cookie” → 错，Session 是服务端状态，Cookie 只是常见携带方式。
• “Session 不使用 Token” → 错，Session ID / Session Token 本身就是凭证。
• “JWT + Session 一定每请求查数据库” → 不一定，Hybrid 可以只在 Refresh / Lifecycle 操作查。
• “Session 是旧式方案” → 不成立；它在需要可撤销登录生命周期的系统中仍然非常自然。

最短记忆

Session 是服务端长期登录状态；Session Token 是客户端访问这份状态的凭证。纯 Session 每请求查状态，Hybrid 则可以只把 Session 用作长期生命周期权威。