前端如何管理JWT的ACCESS Token与REFRESH Token？

1. 如何将Access Token放入Authorization Header #

这是行业标准的认证方式，直接在请求头中添加Authorization字段，格式为Bearer <你的Access Token>，以下是常用请求库的实现示例：

Fetch API示例 #

const accessToken = '你的Access Token值';
fetch('/api/protected-resource', {
  method: 'GET',
  headers: {
    'Authorization': `Bearer ${accessToken}`,
    'Content-Type': 'application/json'
  }
})

Axios示例 #

const accessToken = '你的Access Token值';
axios.get('/api/protected-resource', {
  headers: {
    'Authorization': `Bearer ${accessToken}`
  }
})

2. 直接存在变量中是否安全？ #

• 内存变量仅在当前页面会话有效，页面刷新或关闭后就会消失，短期存储是安全的，但如果页面存在XSS漏洞，攻击者可通过注入脚本窃取内存中的Token。
• 不能依赖内存变量长期保存Token，多页面跳转或刷新后会丢失，必须结合其他存储方式（如sessionStorage）兜底，但sessionStorage同样存在XSS风险，核心原则是：Access Token尽量减少暴露时长，Refresh Token必须用HttpOnly Cookie存储。

3. 多页面应用（MPA）的令牌传递方案 #

MPA页面跳转时内存变量会重置，推荐以下几种可行方案：

• sessionStorage存储Access Token：同一域名下的所有页面共享sessionStorage，页面跳转后可直接读取，关闭浏览器后自动清除，适合存储短期有效的Access Token；缺点是存在XSS窃取风险，需做好页面的XSS防护。
• HttpOnly Cookie存储Refresh Token：页面跳转后Cookie依然有效，每次请求自动携带，新页面加载完成后，调用刷新接口用Refresh Token获取新的Access Token，存入内存或sessionStorage。
• 后端模板嵌入：如果是服务器渲染的MPA，可以在页面模板中通过script标签注入全局变量（如window.__INITIAL_ACCESS_TOKEN__），页面加载时直接读取；注意要对Token做转义处理，防止XSS注入。

⚠️ 绝对不要用URL参数传递Token，会暴露在地址栏、浏览器历史记录和服务器日志中，风险极高。

4. Cookie中Refresh Token获取新Access Token的标准流程 #

这是目前业界通用的安全方案，完整流程如下：

1. 登录阶段：
   • 用户登录成功后，后端返回Access Token（短期有效，比如15分钟），同时设置Refresh Token为HttpOnly、Secure、SameSite=Strict的Cookie（有效期更长，比如7天），并将Refresh Token存入用户数据库。
2. Token过期处理：
   • 前端发起认证请求时，如果返回401 Unauthorized，判断是Access Token过期后，调用刷新接口（如POST /api/refresh）。
   • 该请求会自动携带Cookie中的Refresh Token，后端验证Token的签名、有效期以及是否在数据库中存在。
   • 验证通过后，后端返回新的Access Token（可选同时返回新的Refresh Token，实现Token旋转），并更新数据库中的Refresh Token记录。
   • 前端用新的Access Token重发之前失败的请求，同时更新本地存储的Access Token。
3. 安全注意事项：
   • Refresh Token必须设置HttpOnly属性，禁止前端JavaScript读取，避免XSS窃取。
   • 开启Secure属性，仅在HTTPS请求中携带Cookie。
   • 设置SameSite=Strict或Lax，防止CSRF攻击。
   • 后端要维护Refresh Token黑名单，处理用户注销、Token过期或被盗的情况，确保失效Token无法再使用。
   • 刷新接口要添加限流机制，防止暴力攻击。

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