一、为什么需要双Token？传统JWT鉴权的困境

在单Token模式下，JWT（JSON Web Token）通常同时承担身份验证与授权的双重职责。这种设计在简单场景下运行良好，但当面临Token过期、安全风险或权限变更时，会暴露出明显缺陷：

1. 安全与体验的矛盾
   若设置较短的过期时间（如15分钟），用户需频繁登录；若设置较长过期时间（如7天），一旦Token泄露，攻击者可长期持有权限。

2. 权限变更的滞后性
   当用户角色被管理员撤销（如从管理员降为普通用户），已签发的长时效Token仍可继续使用，导致权限控制失效。

3. 暴力破解风险
   单Token模式下，攻击者只需破解一个Token即可获取全部权限，而双Token可通过分离敏感操作Token降低风险。

双Token的核心设计思想

双Token体系通过功能解耦解决上述问题，其核心原则为：

• Access Token（短期）：用于实际API调用，时效短（如15分钟），包含用户基础信息与权限标识。
• Refresh Token（长期）：用于获取新的Access Token，时效长（如7天），不包含敏感信息，仅作为身份凭证。

这种设计实现了安全与体验的平衡：短期Token限制攻击窗口，长期Token减少用户操作中断。

二、双Token实现的关键步骤

1. Token签发流程

// 伪代码示例：用户登录后签发双Token
const signTokens = (userId, roles) => {
  const accessPayload = {
    sub: userId,
    roles,
    exp: Date.now() / 1000 + 15 * 60 // 15分钟后过期
  };
  const refreshPayload = {
    sub: userId,
    exp: Date.now() / 1000 + 7 * 24 * 60 * 60 // 7天后过期
  };
  const accessToken = jwt.sign(accessPayload, ACCESS_SECRET);
  const refreshToken = jwt.sign(refreshPayload, REFRESH_SECRET);
  // 存储Refresh Token到数据库（可选）
  db.saveRefreshToken(userId, refreshToken);
  return { accessToken, refreshToken };
};

关键点：

• 使用不同密钥（ACCESS_SECRET/REFRESH_SECRET）签发Token
• Refresh Token可选择性存入数据库，用于实现”一次性使用”或”设备绑定”

2. 前端拦截与刷新机制

前端需实现双重拦截逻辑：

// Axios拦截器示例
axios.interceptors.response.use(
  response => response,
  async error => {
    const originalRequest = error.config;
    // 401错误且未重试过
    if (error.response.status === 401 && !originalRequest._retry) {
      originalRequest._retry = true;
      try {
        const refreshToken = localStorage.getItem('refreshToken');
        const res = await axios.post('/auth/refresh', { refreshToken });
        // 更新双Token
        localStorage.setItem('accessToken', res.data.accessToken);
        localStorage.setItem('refreshToken', res.data.refreshToken);
        // 重试原请求
        originalRequest.headers.Authorization = `Bearer ${res.data.accessToken}`;
        return axios(originalRequest);
      } catch (refreshError) {
        // 刷新失败，跳转登录
        window.location.href = '/login';
        return Promise.reject(refreshError);
      }
    }
    return Promise.reject(error);
  }
);

优化建议：

• 设置刷新请求的并发控制，避免重复刷新
• 实现Token预加载，在Access Token即将过期时主动刷新

3. 后端验证与刷新接口

后端需实现严格的Refresh Token验证：

// 伪代码：刷新Token接口
app.post('/auth/refresh', async (req, res) => {
  const { refreshToken } = req.body;
  try {
    // 验证Refresh Token
    const decoded = jwt.verify(refreshToken, REFRESH_SECRET);
    // 可选：检查数据库中的Token有效性
    const storedToken = await db.getRefreshToken(decoded.sub);
    if (storedToken !== refreshToken) {
      return res.status(403).json({ error: 'Invalid refresh token' });
    }
    // 签发新的双Token
    const newTokens = signTokens(decoded.sub, decoded.roles);
    // 更新数据库中的Refresh Token（实现一次性使用）
    await db.updateRefreshToken(decoded.sub, newTokens.refreshToken);
    res.json(newTokens);
  } catch (err) {
    res.status(403).json({ error: 'Token refresh failed' });
  }
});

安全增强措施：

• 限制Refresh Token的使用次数（如每次刷新后失效）
• 实现设备绑定，每个设备保存独立的Refresh Token
• 记录Token的签发与使用日志，便于审计

三、无感刷新的高级技巧

1. 前端预加载策略

通过计算Token剩余有效期，提前发起刷新请求：

// 检查Token过期时间（从Token中解析或本地记录）
const checkTokenExpiration = () => {
  const accessToken = localStorage.getItem('accessToken');
  if (!accessToken) return;
  try {
    const decoded = jwt.decode(accessToken);
    const expiresIn = decoded.exp * 1000 - Date.now();
    // 提前5分钟刷新
    if (expiresIn < 5 * 60 * 1000) {
      refreshTokens();
    }
  } catch (e) {
    console.error('Token解析失败');
  }
};
// 每分钟检查一次
setInterval(checkTokenExpiration, 60 * 1000);

2. 后端滑动过期机制

后端可实现滑动过期（Sliding Expiration），每次刷新时重置Refresh Token的过期时间：

// 修改后的刷新逻辑
const slidingRefresh = async (userId) => {
  const newRefreshExp = Date.now() / 1000 + 7 * 24 * 60 * 60;
  const newRefreshPayload = {
    sub: userId,
    exp: newRefreshExp
  };
  const newRefreshToken = jwt.sign(newRefreshPayload, REFRESH_SECRET);
  await db.updateRefreshToken(userId, newRefreshToken, newRefreshExp);
  return newRefreshToken;
};

3. 多设备管理方案

对于需要支持多设备登录的场景，可实现设备指纹机制：

// 签发时记录设备信息
const signTokensWithDevice = (userId, roles, deviceId) => {
  const accessPayload = { sub: userId, roles, exp: ... };
  const refreshPayload = { 
    sub: userId, 
    deviceId, // 绑定设备
    exp: ... 
  };
  // 存储设备-Token映射
  db.saveDeviceToken(userId, deviceId, refreshToken);
  return { accessToken, refreshToken };
};
// 刷新时验证设备
app.post('/auth/refresh', (req, res) => {
  const { refreshToken, deviceId } = req.body;
  const decoded = jwt.verify(refreshToken, REFRESH_SECRET);
  const storedDevice = db.getDeviceToken(decoded.sub, deviceId);
  if (storedDevice !== refreshToken) {
    return res.status(403).json({ error: 'Device mismatch' });
  }
  // ...继续刷新逻辑
});

四、部署与监控建议

1. 密钥管理最佳实践

• 使用HSM（硬件安全模块）或KMS（密钥管理服务）存储密钥
• 定期轮换密钥（建议每90天）
• 为Access Token和Refresh Token使用不同密钥

2. 日志与监控指标

关键监控项：

• Token签发频率（异常升高可能表示攻击）
• 刷新请求成功率
• 设备绑定数量变化
• 过期Token的使用尝试

3. 降级方案

在网络异常或后端服务不可用时，前端应实现：

• 本地缓存最近可用的Access Token
• 显示友好的错误提示而非直接退出
• 记录失败请求，待网络恢复后重试

五、常见问题与解决方案

Q1：Refresh Token被盗用怎么办？
A：实现Refresh Token一次性使用，每次刷新后立即失效；结合设备指纹限制使用范围。

Q2：如何处理并发刷新请求？
A：后端接口需实现幂等性，可通过在数据库中标记Token状态或使用分布式锁。

Q3：双Token会增加数据库压力吗？
A：若Refresh Token不存数据库则无影响；若需存储，可采用Redis等缓存方案降低压力。

通过双Token与无感刷新机制，开发者可在保证系统安全性的同时，显著提升用户体验。实际实施时需根据业务需求调整过期时间、存储策略等参数，并通过充分的测试验证各边界场景。