如何基于OAuth2无需重新认证即可刷新访问令牌？

这确实是前后端鉴权中很常见的痛点——被动等401再处理会导致用户被强制登出，体验很差；而单纯靠过期时间触发又容易踩令牌失效的坑。要实现像Facebook、谷歌那样的持久登录（直到用户主动登出），核心是把被动补救改成主动预判+静默刷新，结合安全的刷新令牌机制，具体可以这么落地：

一、提前预判令牌过期时间，主动触发刷新 #

不要等令牌完全失效才行动，而是在令牌剩余有效期的某个阈值内（比如剩下5分钟），自动发起刷新请求：

• 存储访问令牌时，同时保存令牌过期时间戳：如果是JWT，可以直接从payload的exp字段解析出过期时间；如果是后端返回的，直接存下来就行。
• 每次发起API请求前，先计算当前时间和过期时间的差值：如果差值小于设定的阈值（比如300秒），就优先调用刷新令牌接口，拿到新令牌后再继续原请求。
• 处理并发请求冲突：用一个全局的"刷新锁"（比如Promise状态锁），避免多个请求同时触发刷新接口。正在刷新时，把后续请求加入队列，等刷新完成后统一用新令牌重试。

二、用静默刷新机制，完全避免登录跳转 #

刷新令牌的过程要对用户完全无感，核心是依赖**刷新令牌（Refresh Token）**而非过期的访问令牌：

• 后端提供专门的刷新接口：只认有效的刷新令牌，不需要携带过期的访问令牌。接口返回新的访问令牌、新的过期时间，建议同时返回新的刷新令牌（滚动更新，提升安全性）。
• 安全存储刷新令牌：优先存在HttpOnly、Secure、SameSite属性的Cookie中（防止XSS攻击）；如果必须存在前端，要加密存储，并且定期清理。
• 只有当刷新令牌也失效/被吊销时，才跳转到登录页——这才是真正需要用户重新认证的场景。

三、全局请求拦截器统一封装逻辑 #

把令牌检查、刷新、队列处理的逻辑封装到请求拦截器里，不用每个请求单独写代码，举个Axios的示例：

let isRefreshing = false;
let refreshRequestQueue = [];

// 请求拦截器
axios.interceptors.request.use(async (config) => {
  const accessToken = localStorage.getItem('accessToken');
  const tokenExpireTime = parseInt(localStorage.getItem('tokenExpireTime'));
  const now = Date.now();

  // 令牌快过期且未在刷新中，触发刷新
  if (tokenExpireTime - now < 300000 && !isRefreshing) {
    isRefreshing = true;
    try {
      // 调用刷新接口，用refreshToken获取新令牌
      const refreshRes = await axios.post('/api/auth/refresh', {
        refreshToken: getCookie('refreshToken') // 假设refreshToken存在HttpOnly Cookie中，后端可直接读取
      });
      // 更新本地存储的令牌和过期时间
      localStorage.setItem('accessToken', refreshRes.data.accessToken);
      localStorage.setItem('tokenExpireTime', refreshRes.data.expireTime);
      // 更新当前请求的令牌
      config.headers.Authorization = `Bearer ${refreshRes.data.accessToken}`;
      // 处理队列中等待的请求
      refreshRequestQueue.forEach(cb => cb(refreshRes.data.accessToken));
      refreshRequestQueue = [];
    } catch (err) {
      // 刷新失败（比如refreshToken过期），才跳转登录
      window.location.href = '/login';
    } finally {
      isRefreshing = false;
    }
  } else if (isRefreshing) {
    // 正在刷新时，把请求加入队列等待
    return new Promise(resolve => {
      refreshRequestQueue.push((newToken) => {
        config.headers.Authorization = `Bearer ${newToken}`;
        resolve(config);
      });
    });
  }

  // 令牌正常，直接携带
  if (accessToken) {
    config.headers.Authorization = `Bearer ${accessToken}`;
  }
  return config;
});

四、刷新令牌的持久化与安全细节 #

要实现真正的持久登录，刷新令牌的策略很关键：

• 设置足够长的有效期：比如7天到30天，对应用户的"记住我"状态。
• 滚动更新刷新令牌：每次刷新访问令牌时，返回新的刷新令牌，旧的立即失效——避免刷新令牌被窃取后长期复用。
• 闲置过期：如果用户连续30天未使用应用，自动失效刷新令牌，此时需要重新登录。

五、边缘情况处理 #

• 页面刷新时：加载页面后先检查令牌是否快过期，若快过期则先触发刷新，再渲染页面内容。
• 刷新接口返回401：说明刷新令牌无效（比如被用户主动登出、被后端吊销），直接跳转登录。

这种方案完全规避了被动等待401的尴尬，用户在正常使用过程中完全感知不到令牌刷新的操作，直到主动登出或者长期闲置才需要重新认证，和大厂的持久登录逻辑一致。

内容的提问来源于stack exchange，提问作者kaos