一、为什么需要双token机制？

传统单token认证存在两大痛点：安全性不足与用户体验差。单token模式下，token既承载身份验证功能，又需频繁刷新以降低泄露风险，导致用户被迫频繁登录。而双token机制通过分离权限与刷新功能，实现了安全与体验的平衡。

核心设计思想：

• Access Token（AT）：短期有效（如15分钟），用于API请求鉴权，权限范围明确。
• Refresh Token（RT）：长期有效（如30天），用于获取新的AT，权限范围受限（如仅刷新）。

典型场景：用户登录后，客户端存储AT与RT。AT过期时，客户端自动使用RT向服务端申请新AT，全程无需用户交互，即”无感刷新”。

二、双token实现关键步骤

1. 登录流程设计

// 前端登录请求示例
async function login(username, password) {
  const response = await fetch('/api/auth/login', {
    method: 'POST',
    body: JSON.stringify({ username, password })
  });
  const data = await response.json();
  // 存储双token（建议使用HttpOnly Cookie或加密存储）
  localStorage.setItem('access_token', data.accessToken);
  localStorage.setItem('refresh_token', data.refreshToken);
}

服务端处理逻辑：

1. 验证用户名密码
2. 生成AT（JWT格式，含短有效期）
3. 生成RT（随机字符串，存入数据库并关联用户）
4. 返回双token

2. 请求鉴权与AT刷新

// 封装带AT的请求
async function fetchWithAuth(url, options) {
  const at = localStorage.getItem('access_token');
  try {
    return await fetch(url, {
      ...options,
      headers: {
        'Authorization': `Bearer ${at}`
      }
    });
  } catch (error) {
    if (error.status === 401) {
      // AT过期，尝试无感刷新
      const newAt = await refreshAccessToken();
      if (newAt) {
        // 重试原请求（实际实现需更严谨）
        return fetchWithAuth(url, options);
      }
    }
    throw error;
  }
}
// 刷新AT
async function refreshAccessToken() {
  const rt = localStorage.getItem('refresh_token');
  const response = await fetch('/api/auth/refresh', {
    method: 'POST',
    headers: { 'Authorization': `Bearer ${rt}` }
  });
  if (response.ok) {
    const data = await response.json();
    localStorage.setItem('access_token', data.accessToken);
    return data.accessToken;
  }
  // 刷新失败，跳转登录页
  window.location.href = '/login';
}

服务端刷新逻辑：

1. 验证RT有效性（检查数据库）
2. 生成新AT（重置有效期）
3. 返回新AT（不返回新RT）

三、无感刷新的核心挑战与解决方案

1. 并发请求处理

问题：多个请求同时触发AT过期，导致重复刷新。

解决方案：

• 请求队列：第一个请求触发刷新时，其他请求挂起，待新AT返回后重试。
• 锁机制：服务端实现刷新锁，防止RT被重复使用。

2. RT安全存储

风险：RT泄露等同于长期有效登录。

防护措施：

• HttpOnly Cookie：防止XSS攻击窃取RT
• 设备指纹绑定：RT仅在当前设备有效
• 一次性使用：RT刷新后立即失效（需服务端支持）

3. 刷新失败处理

场景：RT过期或被撤销。

最佳实践：

• 前端捕获401错误后尝试刷新
• 刷新失败则清除所有token并跳转登录
• 提供友好的错误提示（如”会话已过期，请重新登录”）

四、进阶优化技巧

1. 滑动窗口刷新

原理：在AT过期前提前刷新，避免用户感知。

实现：

// 检查AT剩余有效期
function checkTokenExpiration() {
  const at = parseJwt(localStorage.getItem('access_token'));
  const expiresIn = at.exp - Date.now() / 1000;
  if (expiresIn < 300) { // 剩余5分钟时刷新
    refreshAccessToken();
  }
}
// 每分钟检查一次
setInterval(checkTokenExpiration, 60000);

2. 多设备管理

需求：支持用户在不同设备登录，同时限制活跃设备数。

方案：

• 服务端维护RT与设备的关联关系
• 用户登录新设备时，可选择使旧设备RT失效
• 提供设备管理界面

3. 性能优化

指标：

• 刷新请求耗时（目标<200ms）
• 失败重试次数（建议≤1次）

优化手段：

• RT验证接口轻量化（仅查数据库）
• 使用CDN缓存静态资源
• 预加载关键API数据

五、安全审计要点

1. RT撤销机制：支持即时撤销特定RT（如用户主动登出）
2. 日志记录：完整记录token颁发、刷新、撤销操作
3. 速率限制：防止暴力刷新攻击
4. 定期轮换：定期强制用户重新登录（如每90天）

六、常见问题解答

Q1：双token是否增加服务器负载？
A：实际影响有限。RT验证接口通常仅需数据库查询，且刷新频率远低于AT验证。

Q2：如何选择AT有效期？
A：平衡安全与体验。移动端可设15-30分钟，Web端可稍短（5-15分钟）。

Q3：JWT与Session方案如何选择？
A：JWT适合分布式系统，但撤销困难；Session方案更灵活但需维护状态。双token机制均可适配。

七、完整代码示例（Node.js服务端）

// 登录接口
app.post('/api/auth/login', async (req, res) => {
  const { username, password } = req.body;
  const user = await validateUser(username, password);
  const at = generateAccessToken(user.id); // 15分钟有效期
  const rt = generateRefreshToken(user.id); // 存入Redis，30天有效期
  res.json({
    accessToken: at,
    refreshToken: rt
  });
});
// 刷新接口
app.post('/api/auth/refresh', async (req, res) => {
  const rt = req.headers.authorization?.split(' ')[1];
  const userId = await verifyRefreshToken(rt); // 验证RT并获取用户ID
  if (!userId) {
    return res.status(401).send('Invalid refresh token');
  }
  const newAt = generateAccessToken(userId);
  res.json({ accessToken: newAt });
});
// 辅助函数
function generateAccessToken(userId) {
  return jwt.sign({ userId }, 'ACCESS_SECRET', { expiresIn: '15m' });
}
async function verifyRefreshToken(rt) {
  // 实际实现需查询Redis/数据库
  const storedRt = await redis.get(`rt:${rt}`);
  if (!storedRt) return null;
  // 验证通过后删除该RT（实现一次性使用）
  await redis.del(`rt:${rt}`);
  return storedRt.userId;
}

八、总结与建议

双token机制通过职责分离解决了单token的固有矛盾，而无感刷新则极大提升了用户体验。实施时需重点关注：

1. 安全存储：优先采用HttpOnly Cookie
2. 异常处理：完善刷新失败后的降级方案
3. 监控体系：实时跟踪token相关错误率

对于高安全要求的系统，可进一步结合OAuth 2.0规范，实现标准化的双token流程。实际开发中，建议先实现基础功能，再逐步优化细节。