刷新令牌轮换的三大控制：滑动过期与绝对上限的工程化落地（Node.js/Express 实战）

导语：当电商应用引入手机一次性验证码登录后，刷新令牌的策略边界发生了本质变化：机器人不会因为“保持会话活跃”就变成真实买家。活动可以延长空闲截止时间，但绝不能推动原始绝对截止时间。本文从架构师视角拆解三重控制——空闲超时、凭证轮换、绝对生命周期上限，并给出 Node.js/Express 共享会话状态下的工业级落地与审计证据链设计。

一、问题本质：为什么“活动即续期”是危险的默认值

很多团队在实现刷新令牌时，默认采用“每次刷新就把过期时间往后推”的滑动过期模型。单看用户体验无可厚非，但在结账（Checkout）这类高价值场景下，它埋下了两类结构性隐患：

• 凭证价值被无限放大：一旦刷新令牌被窃取，攻击者只要持续提交刷新请求，就能让会话永久存活，原始登录时间被不断覆盖，事后无法还原。
• 活动与行为无法区分：刷新流量被计入“活跃”，脚本的机械请求与真实买家的浏览行为在监控上完全等价，绿色请求计数器掩盖了真正致命的失败。

因此，正确的策略不变量可以浓缩成一句话：活动可以延长空闲截止时间，但绝不能移动原始绝对截止时间。围绕这个不变量，我们落地三重控制。

二、三重控制模型拆解

2.1 控制一：空闲超时（Idle Timeout）

空闲超时定义“多久没有活动就失效”。它解决的是闲置会话长期挂在服务端的问题。示例策略：20 分钟空闲窗口。每次合法活动刷新空闲截止时间，但仅此而已。

2.2 控制二：凭证轮换（Credential Rotation）

每次成功刷新都必须签发新的刷新令牌，并将旧令牌标记为已取代（superseded）。这样即使某个刷新令牌被捕获，其可用价值也被限制在“下一次刷新之前”。轮换同时要求服务端维护令牌家族（token family）与取代关系，以便识别重放。

2.3 控制三：绝对生命周期上限（Absolute Lifetime Cap）

绝对上限从原始登录时刻起算，任何活动都无法推动它。示例策略：8 小时绝对上限。到第 7 小时，活动仍可延长空闲截止时间；到第 8 小时，无论多活跃都必须失效并要求重新认证。

三、Node.js/Express 落地：把决策放在刷新处理器之后

在 Express 应用中，策略执行必须收敛到刷新处理器背后的共享会话状态里，而不是散落在各个路由。核心逻辑是：读取会话 → 校验空闲截止与绝对上限 → 轮换凭证 → 计算下一次过期时间（取较早者）→ 持久化并返回。

// 策略常量：示例值，非服务默认值
const IDLE_WINDOW_MS = 20 * 60 * 1000;        // 20 分钟空闲窗口
const ABSOLUTE_CAP_MS = 8 * 60 * 60 * 1000;   // 8 小时绝对上限

function nextExpiry(session, now) {
  // 滑动截止时间：活动可延长
  const slidingDeadline = now + IDLE_WINDOW_MS;
  // 绝对截止时间：从原始登录时刻起算，永不移动
  const absoluteDeadline = session.createdAt + ABSOLUTE_CAP_MS;
  // 取较早者，保证绝对上限不可被活动推动
  return Math.min(slidingDeadline, absoluteDeadline);
}

function canRefresh(session, now) {
  if (session.revoked) return { ok: false, reason: 'revoked' };
  if (now >= session.createdAt + ABSOLUTE_CAP_MS) {
    return { ok: false, reason: 'absolute_cap_reached' };
  }
  if (now >= session.idleDeadline) {
    return { ok: false, reason: 'idle_timeout' };
  }
  return { ok: true };
}

module.exports = { IDLE_WINDOW_MS, ABSOLUTE_CAP_MS, nextExpiry, canRefresh };

const crypto = require('crypto');
const { nextExpiry, canRefresh } = require('./sessionPolicy');

async function refreshHandler(req, res) {
  const now = Date.now();
  const presented = req.body.refreshToken;
  const session = await sessionStore.findByRefreshToken(presented);

  // 1. 未知或已被取代的凭证：一律拒绝并记录
  if (!session || session.superseded) {
    await auditLog.record({ event: 'refresh_rejected', reason: 'unknown_or_superseded', at: now });
    return res.status(401).json({ error: 'invalid_grant' });
  }

  // 2. 三重控制校验
  const check = canRefresh(session, now);
  if (!check.ok) {
    await auditLog.record({ event: 'refresh_rejected', reason: check.reason, sessionId: session.id, at: now });
    return res.status(401).json({ error: 'invalid_grant' });
  }

  // 3. 轮换：旧令牌标记取代，签发新令牌
  const newToken = crypto.randomBytes(32).toString('base64url');
  session.superseded = true;
  session.replacedBy = newToken;
  await sessionStore.save(session);

  const rotated = {
    id: session.id,
    createdAt: session.createdAt,          // 原始登录时刻保持不变
    refreshToken: newToken,
    idleDeadline: now + 20 * 60 * 1000,
  };
  rotated.expiresAt = nextExpiry(rotated, now);
  await sessionStore.save(rotated);

  await auditLog.record({ event: 'refresh_rotated', sessionId: session.id, at: now });
  return res.json({ refreshToken: newToken, expiresAt: rotated.expiresAt });
}

module.exports = { refreshHandler };

四、审计证据链：让值班工程师能还原决策

一个绿色的请求计数器无法回答关键问题：执行路径是否拒绝了过期或被取代的凭证？证据是否足以让值班工程师重建当时的决策？因此，审计日志必须至少记录以下字段：

• 拒绝原因：revoked / absolute_cap_reached / idle_timeout / unknown_or_superseded，区分不同失败路径。
• 会话标识与时间线：sessionId、原始登录时刻、空闲截止时间、绝对截止时间。
• 取代关系：旧令牌被哪个新令牌取代，便于追踪令牌家族与重放。

五、策略参数与配置建议

以下参数为示例策略选择，并非服务默认值，需结合业务风控等级调整：

// sessionStore 最小接口约定
// findByRefreshToken(token) -> session | null
// save(session) -> void
// 建议使用 Redis 存储，并设置 TTL = 绝对上限剩余时间

// auditLog 最小接口约定
// record({ event, reason, sessionId, at }) -> void
// 建议写入不可篡改的追加日志，便于事后取证

六、总结：不变量优先于参数

刷新令牌轮换的工程价值不在于参数调得多精细，而在于守住一个可写在事故时间线上的不变量：活动延长空闲截止时间，但绝不移动原始绝对截止时间。围绕它落地空闲超时、凭证轮换与绝对上限三重控制，并配套可还原的审计证据链，才能在结账这类高价值场景中把凭证被盗的窗口收敛到可接受范围。