为什么你需要同时拥有 access token 和 refresh token？

Question

IT Interview Practice · Accepted Answer

这两个 token 的存在是为了化解一个直接的矛盾：access token 必须**在每个 request 上发送**（因此暴露得很多），但你又想要**持续很久**的 session，而不必频繁强制登录。你无法在单个 token 里安全地兼得两者——所以你把这份工作拆开。

## 两种角色

- **Access token** — 短寿命（通常 5–15 分钟），在每次 API 调用时放在 `Authorization` header 中发送。因为它被不断传输，泄露很可能发生；保持其短命意味着被偷走的那个几乎立刻就过期。
- **Refresh token** — 长寿命（数天/数周），**仅**发送到 auth 服务器的 token endpoint 以换取新的 access token。它极少在网络上传输，可以更安全地存储，并且可以在服务端被撤销。

```
Login ──▶ access (15m) + refresh (30d)
每次 API 调用 ──▶ 发送 access
Access 已过期 ──▶ 发送 refresh ──▶ 新 access (+ 轮换后的 refresh)
```

## 为什么不只用一个 token？

| | 一个长寿命 access token | Access + refresh |
|---|---|---|
| 暴露 | 每个 request 都发送、存活久 → 盗窃窗口大 | Access 短寿命；refresh 极少发送 |
| 撤销 | 难（stateless JWT 无法收回签发） | 撤销 refresh token；access 在几分钟内失效 |
| UX | 若短命则频繁重新登录 | 无需重新输入凭据即可保持登录 |
| 泄露的影响半径 | 大 | 小（access 很快过期） |

- **一个短 access token、没有 refresh** → 安全，但用户每隔几分钟就被登出。UX 糟糕。
- **一个长 access token** → UX 很好，但泄露的 token 长时间有效且难以撤销。
- **Access + refresh** → 既有短暴露窗口*又*有长 session。Refresh token 是唯一的长寿命密钥，而它待在一个安全的地方。

## 这种拆分带来了什么

- **尽管 access token 是 stateless 仍可撤销。** 你无法在 JWT access token 过期前使其失效，但你*可以*删除/拒绝 refresh token，于是 session 在下一次 refresh 时（几分钟内）结束。
- **Refresh token rotation（轮换）** — 每次使用时签发一个新的 refresh token，并检测旧的（已用过的）被再次出示（这是被盗的信号），然后撤销整条链。
- **最小暴露** — 长寿命密钥（refresh）只发送到恰好一个 endpoint，理想情况下存储在 `httpOnly` cookie 中，避开 XSS 的触及。

## 为什么这很重要

这是现代标准的 auth 设计，面试官问它是想看你是否理解*为什么*，而不仅仅是*怎么做*。关键洞见在于取舍：无状态与短暴露（access）对长 session 与可撤销性（refresh）。做错了——一个长寿命 access token、没有 rotation、把 refresh 存在 `localStorage` 里——就会把单个泄露的 token 变成长期的账户失陷。说得出这种拆分以及每个 token 各自换来了什么，正是一个有安全意识的工程师应当知道的。

	一个长寿命 access token	Access + refresh
暴露	每个 request 都发送、存活久 → 盗窃窗口大	Access 短寿命；refresh 极少发送
撤销	难（stateless JWT 无法收回签发）	撤销 refresh token；access 在几分钟内失效
UX	若短命则频繁重新登录	无需重新输入凭据即可保持登录
泄露的影响半径	大	小（access 很快过期）

两种角色

为什么不只用一个 token？

这种拆分带来了什么

为什么这很重要

相关问题