JWT认证：Refresh Token存储、原理及AccessToken过期请求处理

一、Refresh Token的客户端存储位置选择 #

• 优先采用HttpOnly + Secure + SameSite=Strict/Lax的Cookie存储Refresh Token，同时设置Path=/api/refresh-token。这种配置下，只有请求刷新Token的接口时才会携带该Cookie，避免随所有业务请求发送，既防范了XSS攻击，又减少了不必要的请求开销。
• 若因跨端场景限制需在前端内存暂存，务必避免写入localStorage/sessionStorage等持久化存储，且页面刷新后需引导用户重新完成认证流程，降低Token泄露风险。

二、AccessToken过期后的请求自动续接方案 #

前端可通过请求拦截器实现无感知续接，核心流程如下：

• 封装全局请求拦截器，捕获响应中的401 Unauthorized状态码（后端需明确用该状态码标识AccessToken过期）。
• 拦截到401后，判断是否正在执行Token刷新操作：
  • 若未刷新，调用刷新Token接口，用Refresh Token换取新的AccessToken和Refresh Token（后端需返回新的Token对）。
  • 若正在刷新，将当前请求加入等待队列，待Token刷新完成后统一重试。
• 刷新成功后，更新客户端的AccessToken（若存在HttpOnly Cookie，后端会自动通过Set-Cookie头更新），并重试原请求；若刷新失败（如Refresh Token过期），则清除本地认证信息，跳转至登录页面。
• 注意：后端需给刷新接口添加频率限制，同时保证接口幂等性，避免重复生成Token。

三、为何用Refresh Token存DB而非直接存储AccessToken #

• 保留JWT无状态优势：AccessToken设计为无状态，本身包含身份信息，后端验证时仅需校验签名和过期时间，无需查询数据库，能大幅提升接口性能。若将AccessToken存入DB，每次请求都要查库验证，完全违背JWT的设计初衷。
• 支持主动失效：Refresh Token生命周期更长，需要实现主动失效（如用户登出、账号冻结）。将其存入DB后，后端可通过删除或标记该Token来即时终止其有效性——这是无状态的AccessToken无法做到的，因为JWT一旦签发，无法主动撤销。
• 安全风险控制：AccessToken有效期短，即使泄露危害时间有限；而Refresh Token有效期长，存入DB可实现精准的权限回收。若用过期AccessToken生成新Token，既无法证明用户当前认证状态，也无法实现主动登出，存在严重安全隐患。

内容的提问来源于stack exchange，提问作者mmierzwa