token设计方案
常见的 Go Gin Web 项目的 Token 刷新方案设计思路：
---
### 1. 采用双 Token 机制（Access Token + Refresh Token）
- **Access Token**：用于接口鉴权，生命周期较短（如15分钟~1小时），一般用JWT实现。
- **Refresh Token**：用于刷新 Access Token，生命周期较长（如7天~30天），通常存储在数据库或Redis中。
---
### 2. 登录流程
1. 用户登录成功后，服务端生成一对 Access Token 和 Refresh Token。
2. Access Token 通过HTTP响应返回给前端，通常放在响应体或HTTP Only Cookie中。
3. Refresh Token 也返回给前端，建议放在HTTP Only Cookie，防止XSS攻击。
---
### 3. 访问受保护接口
- 前端每次请求时携带 Access Token（如放在 Authorization Header）。
- 服务端校验 Access Token，有效则放行，无效则返回401。
---
### 4. Token 过期处理
- 当前端收到 Access Token 过期（401）时，自动携带 Refresh Token 调用刷新接口（如 `/auth/refresh`）。
- 服务端校验 Refresh Token：
- 有效且未过期：生成新的 Access Token（可选：也生成新的 Refresh Token），返回给前端。
- 无效或已过期：要求用户重新登录。
---
### 5. Refresh Token 存储与失效
- Refresh Token 建议存储在数据库或Redis，便于主动失效（如用户登出、修改密码等）。
- 每次刷新时可选择“滑动过期”策略（即刷新时延长有效期），也可选择固定过期时间。
---
### 6. 安全建议
- Refresh Token 只通过HTTP Only Cookie传递，防止被JS获取。
- Access Token 过期时间要短，减少泄露风险。
- 刷新接口要有频率限制，防止暴力攻击。
- 支持Refresh Token黑名单机制，便于主动失效。
---
### 7. 登出/异常处理
- 用户主动登出时，服务端应删除/作废对应的 Refresh Token。
- 检测到异常（如多地登录、密码修改等）时，服务端可主动失效相关 Refresh Token。
---
### 8. 方案流程图
1. 登录 -> 生成 Access Token + Refresh Token
2. 正常请求 -> 校验 Access Token
3. Access Token 过期 -> 用 Refresh Token 换新 Access Token
4. Refresh Token 过期/无效 -> 重新登录