这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。
会话模型
Token 是凭证，会话是登录态
上一章的 Token 解决的是「怎么证明身份」，这一章要解决「登录态怎么管」：用户当前在哪些设备上登录、什么时候过期、怎么续期、怎么撤销、出风险时怎么强制下线。
即使你用了 JWT，也强烈建议保留服务端会话记录。会话是登录态的「账本」，没有它，很多安全能力无从谈起。
一条会话记录
一条会话记录通常包含这些字段：
| 字段 | 含义 |
|---|---|
| session_id | 会话唯一标识 |
| user_id | 所属用户 |
| device_id | 设备或客户端标识 |
| created_at | 登录时间 |
| last_seen_at | 最近活跃时间 |
| expires_at | 过期时间 |
| revoked_at | 撤销时间 |
| risk_level | 当前风险等级 |
| assurance_level | 信任等级（是否已过 MFA） |
为什么即使用了 JWT 也要会话
JWT 自己就能验签，那会话记录是不是多余？不是。会话记录专门负责 JWT 做不了的事：
- 设备管理：用户查看「哪些设备登录过」，需要会话清单。
- 强制下线：撤销某一台设备，需要精确定位到那条会话。
- 风险审计：异常会话的定位、风控，依赖会话状态。
- Refresh Token 撤销：刷新链路的撤销状态，挂在会话上。
一句话：JWT 负责传输身份，会话负责管理状态。 两者搭配，而不是二选一。
会话与 Token 的关系
用下面的关系理解这三者：
用户登录
└─> 创建会话 session（记录设备、过期、风险）
└─> 签发 Access Token（短期，指向会话）
└─> 签发 Refresh Token（长期，挂在会话下）- Access Token 过期 → 用 Refresh Token 刷新（不新建会话）。
- 会话被撤销 → 挂在其下的 Refresh Token 全部失效，Access Token 靠短有效期快速失效。
- 会话过期 → 要求重新登录（走认证流程，新建会话）。
一个值得注意的点
会话记录是登录态的核心数据，写入和读取都在认证链路的关键路径上。它需要：
- 存储在 Redis 等高性能介质（查询快、带 TTL）。
- 可审计：谁在何时创建 / 撤销了会话。
- 可扩展：能支撑设备管理、风控、强制下线等多种能力。
下一节看会话的生命周期策略——什么时候该过期，怎么续期。