Webapp令牌管理与刷新实战指南

本篇文章主要是结合我之前面试的各种经历和实战开发中遇到的问题解决经验整理的，希望这篇《Webapp 令牌使用与刷新实战教程》对你有很大帮助！欢迎收藏，分享给更多的需要的朋友学习~

本文详解 Web 应用中 JWT 访问令牌（Access Token）与刷新令牌（Refresh Token）的安全分发、前端存储、自动续期及无感登录实现方案，涵盖 JSON 响应格式、Bearer 认证头设置、持久化策略选择及 HTTP 拦截器关键实践。

在用户成功登录后，后端应以 JSON 格式返回一对令牌：

{
  "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...",
  "expires_in": 3600
}

前端（如 React、Vue 或 Angular）需安全存储这两个令牌：

• access_token 应优先存入 sessionStorage（关闭标签页即清除），兼顾安全性与会话生命周期；若需支持“记住我”或跨标签页保持登录，可结合 HttpOnly 安全 Cookie 存储（但需注意 XSS 风险），或使用 localStorage + 严格 CSP 策略（不推荐敏感场景）；
• refresh_token 必须长期保密，绝不存于前端可读存储（如 localStorage/sessionStorage）——理想方案是后端将其写入 HttpOnly + Secure + SameSite=Strict 的 Cookie，前端无法通过 JavaScript 访问，仅在刷新请求时由浏览器自动携带。

每次调用受保护 API 时，前端应在请求头中携带访问令牌：

Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

为实现“用户关闭浏览器数小时后再次打开仍自动登录”，关键不在于从 Cookie 直接读取 access_token（因其通常已过期），而在于：

1. 前端启动时，尝试用 refresh_token（自动随 Cookie 发送）向 /auth/refresh 接口发起请求；
2. 后端校验 refresh_token 有效性（签名、黑名单、绑定设备/IP 等），若合法则签发新的 access_token（及可选的新 refresh_token）；
3. 前端接收新 access_token 并更新本地存储，后续请求即可继续使用。

此流程需依赖 HTTP 拦截器（Interceptor） 统一处理：

• 请求拦截：自动注入 Authorization 头；
• 响应拦截：捕获 401 Unauthorized，触发刷新逻辑；刷新成功后重放原请求，失败则跳转登录页。

⚠️ 注意事项：

• access_token 生命周期宜短（如 15–60 分钟），降低泄露风险；
• refresh_token 必须具备强绑定（如用户 ID + 设备指纹 + IP 段）、独立存储、可主动吊销机制；
• 切勿在 URL、日志或前端控制台中明文打印令牌；
• 建议配合 CSRF Token（若 refresh_token 使用 Cookie）防范跨站请求伪造。

通过上述设计，既保障了 API 调用的安全性与效率，又实现了用户友好的“无感续登”体验。

今天关于《Webapp令牌管理与刷新实战指南》的内容介绍就到此结束，如果有什么疑问或者建议，可以在golang学习网公众号下多多回复交流；文中若有不正之处，也希望回复留言以告知！