Refresh Token

这一课你将能做到

1. 说明「短 access + refresh 续期」的分工与安全收益，写出 grant_type=refresh_token 的完整请求
2. 按客户端类型选对 refresh 存储位置：后端 DB/Redis、移动端系统钥匙串，绝不长期放前端 localStorage
3. 实现 rotation（轮换）与重放检测：旧 refresh 再次出现 = 泄露信号，应撤销整条授权

为什么要学

access_token 的寿命是一道两难题：设 7 天，被偷了就是 7 天敞开的大门；设 5 分钟，用户每隔几分钟重新登录，产品没法用。

Refresh token 是标准答案，分工明确：

• access_token：日常开门用，寿命短（几分钟到几十分钟），泄露窗口小；
• refresh_token：只干一件事——去授权服务器换新 access_token，寿命长（天级）但用途单一，不能直接调业务 API。

这套思想你也用在本站的自研 JWT 方案里：backend 签发短寿命 JWT，配合 refresh（或滑动续期）保证体验——第 10 课会专门对比两条轨。而对接第三方 IdP 或自建授权服务器时，refresh 的协议细节（请求形状、轮换、撤销）必须按标准来实现，不能「长寿 access 一发了之」。

面试高频：「为什么 access token 要短」「refresh token 泄露了怎么办」「rotation 是什么」——本课全部给到可背诵、可落地的程度。

先建立图像

登录成功（授权码流换到 token）
  ├─ access_token   15 分钟 ──► 调业务 API（常过期，泄露损失小）
  └─ refresh_token  7~30 天 ─► 仅用于 POST /token 换新 access
                                    │
                        开启 rotation 时：响应同时返回新 refresh
                                    │
                        旧 refresh 立即作废
                                    │
                        若作废的旧 refresh 又被拿来用
                                    └─► 重放！撤销该用户该 Client 的全部授权

按客户端类型选存储位置：

客户端	refresh 放哪	原因
机密后端	服务端 DB/Redis（加密存储）	可绑定用户与客户端，易撤销
SPA	不要长期放 localStorage	XSS 一锅端；优先放 BFF/后端
移动 App	iOS Keychain / Android Keystore	系统级加密保护

跟着做

步骤 1：看清续期请求的形状

# 中文注释：用 refresh 换新 access；按 IdP 要求带 client_id/secret 或客户端标识
curl -i -X POST https://auth.example.com/token \
  -H "Content-Type: application/x-www-form-urlencoded" \
  -d "grant_type=refresh_token" \
  -d "refresh_token=THE_REFRESH_TOKEN" \
  -d "client_id=coderoadmap-web" \
  -d "client_secret=${CLIENT_SECRET}"

期望响应包含新的 access_token、expires_in；若开启 rotation，还有新的 refresh_token——此时旧的立即作废，代码里必须更新存储。

步骤 2：前端感知过期的标准流程（BFF 思路）