Feathers JS：页面刷新时如何验证存储在浏览器Session中的Access Token

嘿，我来给你梳理下实际项目里常用的几种验证思路，都是经过实践检验的：

1. 前端发起轻量验证请求（最通用的方案） #

这是前后端分离架构下的标准操作：

• 页面加载完成后，从sessionStorage里取出存储的Access Token；
• 向后端调用一个专门的Token验证接口（比如GET /api/auth/check-token），把Token放在请求头里（通常用Authorization: Bearer ${token}格式）；
• 后端收到请求后做这几步校验：
  • 先检查Token是否存在、格式是否符合要求；
  • 如果是JWT，直接解析校验签名和过期时间；如果是自定义Token，就查数据库/缓存确认Token是否有效、未被吊销；
  • 返回验证结果：有效则返回用户基础信息或成功状态，无效就返回401状态码。
• 前端收到结果后：有效就继续渲染页面；无效则清除Session里的Token，跳转到登录页。

给你贴个简单的前端实现示例：

window.addEventListener('load', async () => {
  const token = sessionStorage.getItem('accessToken');
  // 没有Token直接跳登录
  if (!token) {
    window.location.href = '/login';
    return;
  }

  try {
    const response = await fetch('/api/auth/check-token', {
      headers: {
        'Authorization': `Bearer ${token}`
      }
    });

    if (!response.ok) throw new Error('Token无效');
    
    // Token有效，拿到用户信息后渲染页面
    const userInfo = await response.json();
    initPage(userInfo);
  } catch (err) {
    // 验证失败，清理Token并跳转登录
    sessionStorage.removeItem('accessToken');
    window.location.href = '/login';
  }
});

2. JWT本地前置校验（配合后端验证） #

如果你的Access Token是JWT格式，可以先在前端做快速校验，减少不必要的后端请求：

• 解析JWT的payload部分，取出exp（过期时间）字段，转成时间戳和当前时间对比；
• 注意：本地校验只能判断是否过期，无法验证签名是否被篡改，所以这一步只是前置过滤，最终必须和后端验证配合使用；
• 示例代码：

function isJwtExpired(token) {
  try {
    // JWT的第二部分是payload，用base64解析
    const payload = JSON.parse(atob(token.split('.')[1]));
    const expireTime = payload.exp * 1000; // 转成毫秒
    return Date.now() > expireTime;
  } catch (err) {
    // 解析失败直接判定为无效
    return true;
  }
}

window.addEventListener('load', async () => {
  const token = sessionStorage.getItem('accessToken');
  if (!token || isJwtExpired(token)) {
    sessionStorage.removeItem('accessToken');
    window.location.href = '/login';
    return;
  }

  // 本地校验通过后，再调用后端接口验证签名有效性
  // 后续逻辑和第一种方案一致...
});

3. 服务端渲染场景：后端主动校验 #

如果是服务端渲染（比如Next.js、Nuxt.js，或者传统PHP/Java后端渲染页面），可以把校验逻辑放在后端：

• 用户刷新页面时，后端先从HttpOnly Cookie或服务端Session中获取Token；
• 后端直接完成Token有效性校验，有效就渲染正常页面内容，无效则直接重定向到登录页；
• 这种方式不需要前端额外发请求，用户体验更流畅，也更安全（Token不会暴露给前端JS）。

一些关键注意事项 #

• 不要在前端存储敏感信息：sessionStorage是前端可访问的，Token本身不要包含用户敏感数据，后端验证通过后再从数据库拉取用户信息；
• 搭配刷新Token机制：给Access Token设置较短的过期时间，同时生成刷新Token存在HttpOnly Cookie中，Token过期时用刷新Token去换新的Access Token，减少用户重新登录的频率；
• 处理Token被主动吊销的情况：比如用户注销、权限变更，即使Token没过期，后端也要能识别并返回无效，前端收到后要及时清理Session。

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