本文详解 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（因其通常已过期），而在于：
- 前端启动时，尝试用 refresh_token（自动随 Cookie 发送）向 /auth/refresh 接口发起请求；
- 后端校验 refresh_token 有效性（签名、黑名单、绑定设备/IP 等），若合法则签发新的 access_token（及可选的新 refresh_token）；
- 前端接收新 access_token 并更新本地存储，后续请求即可继续使用。
此流程需依赖 HTTP 拦截器（Interceptor） 统一处理：
- 请求拦截：自动注入 Authorization 头；
- 响应拦截：捕获 401 Unauthorized，触发刷新逻辑；刷新成功后重放原请求，失败则跳转登录页。
⚠️ 注意事项：
- access_token 生命周期宜短（如 15–60 分钟），降低泄露风险；
- refresh_token 必须具备强绑定（如用户 ID + 设备指纹 + IP 段）、独立存储、可主动吊销机制；
- 切勿在 URL、日志或前端控制台中明文打印令牌；
- 建议配合 CSRF Token（若 refresh_token 使用 Cookie）防范跨站请求伪造。
通过上述设计，既保障了 API 调用的安全性与效率，又实现了用户友好的“无感续登”体验。
