后端开发中Token刷新与重放攻击防范

Token刷新机制是后端会话管理中绕不开的核心环节。很多团队在设计时，只关注了“无感刷新”的用户体验，却忽视了Token刷新接口本身就是一个高危攻击面。攻击者一旦通过中间人攻击、XSS漏洞或日志泄露拿到Refresh Token，就能无限期维持登录状态，甚至在被盗用后，合法用户依然浑然不觉。要解决这个问题，不能只靠延长或缩短Token有效期，而必须从Token的存储、传输、刷新逻辑和异常检测四个维度构建纵深防御。

Access Token通常是一个短期有效的JWT，携带用户身份和权限信息，每次API请求在Authorization头中携带。它的设计目标是“无状态验证”，资源服务器不需要查数据库就能验签和解析。Refresh Token则是一个长期有效的凭证，只发给授权服务器，用于换取新的Access Token。两者分工明确：Access Token负责高频访问，暴露面大但时效短；Refresh Token负责低频续期，暴露面小但危害大。很多系统把Refresh Token也做成JWT，这本身没问题，但必须明确：Refresh Token的生命周期管理必须是有状态的，也就是说，授权服务器必须能主动撤销它。

第一个风险是Refresh Token存储不当。前端Web应用如果把Refresh Token存在localStorage或sessionStorage，任何XSS漏洞都能直接读取。移动端相对安全一些，但如果不使用系统级安全存储（如iOS的Keychain、Android的Keystore），反编译后依然可能泄露。第二个风险是刷新接口没有绑定设备或客户端指纹。攻击者拿到Refresh Token后，可以从完全不同的IP、设备发起刷新请求，而服务端毫无感知。第三个风险是旧Token未失效。很多系统在刷新后，旧的Refresh Token仍然有效，这等于给了攻击者一个时间窗口，可以同时使用新旧Token。第四个风险是并发刷新导致的问题。当多个请求同时因Access Token过期触发刷新时，如果没有锁机制，可能产生多组有效的Token对，增加泄露面。

对于BFF（Backend For Frontend）架构，最佳实践是Refresh Token永远不进入浏览器。浏览器只保存一个HttpOnly、Secure、SameSite=Strict的Session Cookie，由BFF层持有Refresh Token。浏览器发起API请求时，BFF用Refresh Token换取Access Token，再代理请求到资源服务器。这样即使前端存在XSS漏洞，攻击者也读不到Refresh Token。如果无法引入BFF层，Web应用至少要使用Service Worker配合IndexedDB做加密存储，将解密密钥放在内存中，增加攻击难度。移动端必须使用平台提供的安全存储机制，并且配合生物特征验证才能读取。无论哪种存储方式，Refresh Token在传输过程中必须走HTTPS，且建议对Token本身再做一层对称加密，防止在日志或代理层意外泄露。

刷新接口不能只验证Token本身是否有效，还必须验证请求上下文是否与签发时一致。签发Refresh Token时，服务端应记录客户端指纹信息，包括但不限于：IP地址段、User-Agent、设备ID、TLS握手中的Client Random等。刷新时对比这些指纹，如果关键字段发生变化，比如IP归属地从北京变成境外，或者设备ID完全改变，就应该拒绝刷新并触发安全告警。指纹对比策略要有一定弹性，IP地址段可以允许同一运营商内变化，但跨国或跨运营商就应该拦截。设备指纹建议使用服务端下发的加密Cookie或SDK生成的设备ID，而不是前端可篡改的参数。更进一步的方案是Token Binding，将Token与TLS连接绑定，即使Token被窃取，攻击者也无法在其他连接上使用。虽然Token Binding尚未普及，但在高安全场景下值得引入。

每次刷新成功后，必须立即废弃旧的Refresh Token，这就是Token轮换机制。具体实现上，可以在数据库中为每个用户维护一个Refresh Token链表或版本号。签发新Token时，将旧Token标记为已使用或直接删除。如果服务端检测到一个已被废弃的Token再次被使用，说明该Token可能已被窃取，此时应立即废弃该用户所有未过期的Refresh Token，强制重新登录。这种“重用检测”是防范Refresh Token泄露的关键手段。实现时要注意竞态条件：如果用户正常刷新时网络超时，客户端重试可能导致旧Token被误判为重用。解决方法是在废弃旧Token时设置一个短暂的宽限期，或者使用乐观锁机制，确保同一Token只能被消费一次。

前端应用通常会在Axios或Fetch拦截器中统一处理401响应，自动触发Token刷新。当页面上多个请求同时返回401时，如果不加控制，会并发调用刷新接口，造成Token浪费甚至冲突。客户端需要实现一个刷新锁：维护一个全局的Promise队列，第一个401触发刷新时，将刷新Promise缓存起来，后续401请求都等待这个Promise，而不是发起新的刷新请求。刷新成功后，用新的Access Token重放所有等待队列中的请求。刷新失败则统一跳转登录页。这个逻辑看似简单，但要注意处理刷新过程中又有新的401返回的情况，以及刷新接口本身返回401时的死循环问题。刷新接口返回401应直接判定为Refresh Token失效，清除本地状态并跳转登录，不再重试。

重放攻击的核心在于攻击者截获合法请求后，原封不动或稍加修改后重新发送，达到越权操作的目的。Token刷新场景下的重放攻击主要有两种形态：一是截获刷新请求本身，重复使用Refresh Token；二是截获携带Access Token的业务请求，在Token有效期内重复执行。防范重放攻击不能依赖单一手段，需要在多个层次设防。传输层强制使用HTTPS并开启HSTS，防止中间人解密流量。应用层引入Nonce机制，每个请求携带一次性随机数，服务端校验Nonce是否已使用。时间窗口层使用Timestamp配合Nonce，服务端拒绝时间偏差过大的请求。签名层对请求体做哈希签名，防止参数被篡改后重放。

Nonce机制的思路是：客户端为每个请求生成一个全局唯一的随机字符串，服务端维护一个Nonce已用集合。请求到达时，先检查Nonce是否已存在，存在则拒绝，不存在则处理请求并将Nonce加入集合。纯Nonce方案的问题是集合会无限膨胀，需要配合过期清理。更实用的方案是Nonce加Timestamp：客户端生成Nonce，并在请求头中带上当前时间戳。服务端先校验时间戳与服务器时间的偏差是否在允许范围内，再检查Nonce是否在该时间窗口内已使用。这样服务端只需要维护一个滑动窗口内的Nonce集合，过期自动清理。具体实现可以用Redis的Sorted Set，以时间戳为Score，定期删除窗口外的数据。Nonce的生成要保证足够的随机性，建议使用密码学安全的随机数生成器，长度至少128位。

// 服务端防重放校验示例（Node.js + Redis）
async function checkReplay(nonce, timestamp, windowSeconds = 300) {
  const now = Date.now();
  if (Math.abs(now - timestamp) > windowSeconds * 1000) {
    throw new Error('请求时间戳超出允许范围');
  }
  const key = 'nonce:used';
  // 清理窗口外的旧Nonce
  await redis.zremrangebyscore(key, 0, now - windowSeconds * 1000);
  // 检查Nonce是否已存在
  const exists = await redis.zscore(key, nonce);
  if (exists) {
    throw new Error('请求已被处理，可能是重放攻击');
  }
  // 记录Nonce
  await redis.zadd(key, now, nonce);
  return true;
}

Nonce机制能防止完全相同的请求被重放，但如果攻击者修改了请求参数后重放，Nonce本身无法识别。请求签名机制可以解决这个问题。客户端在发送请求前，将请求方法、路径、时间戳、Nonce、请求体等关键字段按约定顺序拼接，使用共享密钥生成HMAC签名，放在请求头中。服务端收到请求后，用同样的方式计算签名并比对。签名不一致说明请求被篡改，直接拒绝。签名机制要求客户端持有密钥，对于Web应用，这个密钥可以通过登录接口动态下发，存储在内存中。对于移动端，密钥可以硬编码但配合代码混淆和完整性校验。签名算法建议使用HMAC-SHA256，性能开销小且安全性足够。需要注意的是，签名机制不能替代Nonce，两者配合使用才能同时防篡改和防重放。

综合以上分析，一个安全的Token刷新架构应该包含以下要素。第一，Refresh Token存储在服务端可控的安全区域，前端只持有间接引用。第二，刷新接口强制验证客户端指纹，指纹变化时拒绝刷新或要求二次认证。第三，严格执行Token轮换，旧Token立即失效，并开启重用检测。第四，客户端实现刷新锁，避免并发刷新。第五，刷新接口本身也要防重放，引入Nonce和Timestamp校验。第六，建立异常监控体系，对刷新频率异常、地理位置突变、设备指纹变化等事件实时告警。第七，提供用户侧的会话管理能力，让用户能查看和主动撤销其他设备的登录状态。这些措施组合起来，能够将Token刷新环节的风险降到可控范围内，即使Refresh Token意外泄露，攻击者能利用的时间窗口和操作空间也会被极大压缩。

安全防护的最后一道防线是监控。需要记录的刷新事件日志包括：用户ID、刷新时间、客户端IP、设备指纹、使用的Refresh Token哈希值、刷新结果。基于这些日志，可以建立基线模型，比如用户通常在北京时间9点到18点之间、从北京IP段刷新，频率约为每小时一次。一旦出现凌晨3点从境外IP刷新、或者一小时内刷新数十次的异常模式，系统应自动触发二次验证或直接冻结账户。应急响应方面，系统必须提供批量撤销Token的能力，当确认发生泄露时，能在分钟级时间内强制所有受影响的会话重新认证。这个能力需要建立在Refresh Token有状态管理的基础上，再次印证了Refresh Token不能做成纯无状态JWT的设计原则。