无感刷新的秘密：Access Token 和 Refresh Token 的那些事儿

在现代 Web 开发中，用户的身份认证和授权是一个绕不开的话题。为了保证安全性，我们通常会使用 token-based 认证机制，其中 Access Token 和 Refresh Token 是实现"无感刷新"体验的关键。今天我们就从 HTTP 请求的角度，聊聊这两者的工作原理和续期逻辑。

一、一般情况下的 HTTP 请求是什么样子？

假设你已经登录了一个网站，服务端返回了 Access Token 和 Refresh Token（通常在登录成功后的响应中）。Access Token 是短期有效的凭证，用于访问受保护的资源。

在日常操作中，比如你想获取用户个人信息，客户端会发起一个这样的 HTTP 请求：

sql 复制代码

GET /api/user/profile HTTP/1.1
Host: example.com
Authorization: Bearer eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...

关键点 ： - Authorization 头携带了 Access Token，格式通常是 Bearer <access_token>。 - 服务端验证这个 token 是否有效（未过期、签名正确等），如果通过，就返回对应的数据，比如： json { "username": "Alice", "email": "[email protected]" }

这种请求是无感知的，用户只需要正常操作，客户端会自动带上 Access Token。

二、续期情况下的 HTTP 请求长啥样？

Access Token 通常有效期较短（比如 15 分钟或 1 小时），一旦过期，客户端就无法直接访问资源了。这时候，Refresh Token 上场，它是一个长期有效的凭证，专门用来换取新的 Access Token。

当 Access Token 过期，客户端会发起一个续期请求，典型的 HTTP 请求如下：

bash 复制代码

POST /api/auth/refresh HTTP/1.1
Host: example.com
Content-Type: application/json

{
  "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9..."
}

关键点 ： - 请求通常是 POST 类型，携带 Refresh Token。 - 服务端验证 Refresh Token 是否有效（未过期、未被撤销等），如果通过，会返回新的 Access Token（有时还会返回新的 Refresh Token）： json { "access_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "refresh_token": "eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9...", "expires_in": 3600 }

客户端拿到新的 Access Token 后，保存下来，后续请求继续使用新的 Access Token，无需用户重新登录。这就是"无感刷新"的核心：用户完全察觉不到 token 的切换。

三、什么时候会发生续期？怎么判定要续期？

续期并不是随便发生的，它有明确的触发条件和判定逻辑。以下是常见的场景和方法：

什么时候发生续期？ - Access Token 过期 ：最常见的情况是 Access Token 到期。比如有效期是 1 小时，过了这个时间，服务端会返回 401 Unauthorized。 - 主动提前续期：为了避免用户请求失败，很多客户端会在 Access Token 快过期时（比如剩余 5 分钟）主动发起续期。
怎么判定要续期？ - 服务端返回 401 ：客户端发送请求时，如果收到 401 状态码，通常意味着 Access Token 已失效，需要用 Refresh Token 去换新的。 - 客户端时间检查 ：Access Token 通常会带上 expires_in（有效期，单位秒）。客户端可以解析 token 或记录下到期时间，提前判断是否需要续期。 - 比如，假设当前时间是 10:00，token 的到期时间是 10:15，客户端可以在 10:10 时提前发起续期请求。 - JWT 自解析 ：如果 Access Token 是 JWT 格式，客户端可以直接解析其 exp（过期时间）字段，计算是否需要续期。
无感刷新的实现： - 客户端通常会设置一个拦截器（interceptor）。每次请求前检查 Access Token 是否有效，快过期就先调用刷新接口；收到 401 时也自动触发刷新流程。 - 用户完全无感知，因为这些操作都在后台默默完成。

总结

通过 Access Token 和 Refresh Token 的配合，我们实现了安全与用户体验的平衡： - Access Token ：短命，负责日常请求，过期后失效。 - Refresh Token ：长寿，负责续期，保障无感体验。 - 续期逻辑：要么被动（401 触发），要么主动（提前检查），客户端聪明地处理一切。

下次你刷网页、用 App 时，如果没有频繁弹出登录框，不妨感谢一下这对 token 兄弟的幕后努力吧！