双 Token 机制解析：提升用户体验的安全认证方案
在现代 Web 与移动应用中，“安全”与“用户体验”往往存在天然冲突：
Token 有效期太短 → 用户频繁掉线、体验差
Token 有效期太长 → 安全风险高，容易被盗用
双 Token（Access Token + Refresh Token）机制正是为了解决这一矛盾，是当前最主流、最均衡、最安全的身份认证方案。
本文将从基础概念、完整流程、对比分析、安全设计，再到 Java 实战示例，提供一套可直接落地的生产级解决方案。
一、双 Token 基本概念
双 Token 机制包含两个角色：
1. Access Token（访问令牌）
作用：访问受保护资源的凭证
特点：
生命周期短（10–30 分钟）
每次 API 调用都必须携带
一旦泄漏风险较低（短期有效）
适合存储位置：内存、localStorage、sessionStorage
2. Refresh Token（刷新令牌）
作用：用于换取新的 Access Token
特点：
生命周期长（7–30 天）
不直接访问资源，只能用于“刷新”
必须安全存储，需可撤销
推荐存储位置：HttpOnly Cookie（防 XSS）
二、双 Token 工作原理
认证流程图：
完整流程说明
1. 初始登录：生成双 Token
前端提交账号密码 → 服务端验证 → 返回：
Access Token（短期）
Refresh Token（长期、一般放在 HttpOnly Cookie）
2. 每次访问 API
请求头携带：
Authorization: Bearer <access_token>3. Access Token 过期时
后台流程：
服务器返回 401（Token 过期）
前端使用 Refresh Token 调用
/refresh接口服务端生成新的 Access Token
前端自动重试原请求
用户完全无感知
4. Refresh Token 过期
用户被要求重新登录。
三、为什么单 Token 机制不够？
下面是单 Token 在实际场景中的痛点：
| 问题 | 描述 | 用户影响 |
|---|---|---|
| 安全性困境 | Toke |
