这是 Beta 探索课程，内容结构、实验步骤和示例可能会继续调整。

续期策略

会话多久过期

会话生命周期设计，本质是在「用户省事」和「风险窗口」之间找平衡。两种极端策略：

策略	做法	体验	风险
固定过期	登录后 7 天必须重新登录	差，到点就被踢	低，窗口固定
滑动过期	持续活跃自动延长	好，一直活跃一直有效	高，窗口可能无限拉长

滑动过期的隐患

滑动过期有个隐藏风险：用户只要保持活跃，会话可以一直延续，理论上永不失效。如果用户长期不退出，一旦设备或凭证泄露，攻击者能用的窗口就是「无限长」。

组合方案

生产系统很少二选一，而是用三个时间点组合：

短期 Access Token：分钟级，控制单次请求暴露窗口。
较长 Refresh Token：天级（如 30 天），用户活跃时自动续期。
绝对生命周期上限：如 30 天，无论多活跃，到点必须重新登录。

这样：

正常用户持续活跃，用 Refresh Token 无感续期，体验好。
但即便一直活跃，超过绝对上限也要重新登录，风险窗口有边界。

续期的可视化

把三个时间点画出来，就是这样的关系：

登录 ──────────────── 绝对上限（30 天）────────────────
  │
  ├── Access（15min）──┐
  │                   ├── 刷新 → 新 Access + 新 Refresh
  └── Refresh（30天）──┘
         （每次刷新轮换，旧的作废）

只要用户在活跃，Refresh Token 会不断续期；但超过 30 天绝对上限，就强制回到登录页。

续期的安全细节

轮换：每次刷新签发新 Refresh Token，旧值作废，防重放。
静默刷新：在后台悄悄刷新 Access Token，用户无感。
阈值控制：活跃度低（长时间无请求）的会话，即使未到上限，也可以要求重新认证。
绝对上限按业务调：金融、内部系统更短；普通内容站点可放宽。

上线检查

是否定义了 Access、Refresh、绝对上限三个时间点？
是否有绝对生命周期上限，防止滑动过期无限拉长？
Refresh Token 是否轮换、绑定设备、可撤销？
活跃度低的会话是否有降级 / 重新认证策略？

会话「活多久」的问题解决了，下一节看怎么「提前掐断」——撤销与强制下线。