认证架构

约 547 字大约 2 分钟

2026-02-15

基础架构是 refresh 放 HttpOnly cookie，access 放内存 + header

目标

长期凭证更安全（不暴露给 JS，降低被盗后跨设备复用风险）
业务请求更可控（用 header 携带 access token，减少 CSRF 面积）
体验不掉线（access 过期后可自动刷新）

凭证分层

Refresh Token（长期）

存放位置：HttpOnly Cookie
特性：长期有效（如 7–30 天）、仅用于换取新的 access token
Cookie 关键属性：
- HttpOnly（JS 读不到）
- Secure（仅 HTTPS）
- SameSite=Lax（跨站才用 None）
- Path=/auth/refresh（强烈建议：只让刷新接口携带）

Cookie 里尽量放 短小的随机串（opaque token），不要塞用户信息。

Access Token / Session Token（短期）

存放位置：JS 内存（变量/状态管理）
特性：短命（如 5–15 分钟），页面刷新/关闭即丢
使用方式：每次业务请求加 header Authorization: Bearer <access_token>

Access token 只放必要信息：userId/sub、roles/scopes、exp 等；用户资料（name/email/displayName）建议走 /me 获取并缓存。

核心流程

登录

前端提交账号密码到 /auth/login
后端验证成功：
- Set-Cookie: refresh=...; HttpOnly; Secure; SameSite=...; Path=/auth/refresh
- 响应 body 返回 access_token（短期）
前端把 access_token 存内存，后续请求都带 Authorization

正常请求

前端调用业务 API：带 Authorization: Bearer <access_token>
后端验证 access token 通过 → 返回数据

Access 过期自动续期

业务请求返回 401（token 过期）
前端调用 /auth/refresh：
- 浏览器自动带 refresh cookie（因为 Path 匹配）
后端校验 refresh token，通过则返回新的 access_token
- 可选：refresh token 轮换（rotation），再发一次 Set-Cookie 更新 refresh
前端更新内存中的 access token，然后重放之前失败的请求

登出

前端调用 /auth/logout
后端清理/作废 refresh，并通过 Set-Cookie 让 refresh 过期（Max-Age=0）

安全要点总结

重要凭证放 HttpOnly Cookie，并缩小作用域（Path=/auth/refresh）
业务接口不依赖 cookie（用 header access token），降低 CSRF 风险
access token 短命 + 内存存储，减少泄露窗口
XSS/CSRF 仍需基础防护：
- CSP、输出编码、依赖治理（防 XSS）
- SameSite 合理设置；必要时 CSRF token（防 CSRF）