Laravel+React基于Sanctum认证：令牌刷新及过期优化疑问

一、每次请求调用刷新令牌API是否合理？ #

完全不合理，原因如下：

• 额外开销暴增：每一次业务请求都附加刷新请求，会大幅增加服务器负载和前端响应时间，纯粹是资源浪费。
• 安全风险提升：刷新令牌本身存在使用限制（比如部分策略下重复刷新会触发失效），频繁调用反而可能导致合法令牌被回收。
• 逻辑冗余：令牌的过期时间是可预判的，完全没必要在每次请求时都触发刷新逻辑。

二、Bearer令牌过期的更优解决方案 #

针对SPA场景，结合Laravel Sanctum的特性，推荐以下几种实用方案：

1. 提前预判过期时间，主动刷新 #

• 核心思路：登录成功后，将令牌的过期时间（比如Sanctum默认1小时）存储在前端（内存或localStorage），设置定时器在令牌过期前5-10分钟自动调用刷新接口，更新令牌和过期时间。
• 具体实现：
  • 后端登录接口返回令牌时，同时返回过期时间戳（或直接告知有效期分钟数）。
  • 前端计算当前时间 + 有效期 - 提前刷新时间，用setTimeout设置定时任务。
  • 配合请求拦截器兜底：每次发起请求前先检查令牌是否快过期，若快过期则先完成刷新再发请求。

2. 请求拦截器+401自动重试 #

• 核心思路：利用Axios等HTTP库的拦截器，在收到401 Unauthorized响应时，先尝试刷新令牌，成功后自动重试原请求。
• 关键细节：
  • 后端需在401响应中明确标识是令牌过期（比如返回{"code": "TOKEN_EXPIRED"}），避免和其他权限不足场景混淆。
  • 加锁机制防止并发刷新：用一个全局变量isRefreshing标记刷新状态，多个请求触发401时，只发起一次刷新，其他请求等待刷新完成后复用新令牌重试。
  • Sanctum侧的刷新接口：在控制器中通过auth()->user()->createToken('spa-token')->plainTextToken生成新令牌，可选择删除旧令牌（auth()->user()->tokens()->where('name', 'spa-token')->delete()）避免令牌泛滥。

3. Http-Only Cookie存储刷新令牌（推荐） #

• 核心思路：结合Sanctum的Cookie安全特性，将刷新令牌存储在Http-Only、Secure的Cookie中，前端无需手动管理刷新令牌的存储，后端负责验证和更新。
• 具体步骤：
  • 登录成功后，后端除了返回Bearer令牌，还通过cookie()->queue('refresh_token', $refreshToken, 1440, null, null, false, true)设置Http-Only Cookie（有效期24小时）。
  • 刷新接口通过request()->cookie('refresh_token')获取刷新令牌，验证用户身份后返回新的Bearer令牌，同时更新Cookie中的刷新令牌。
  • 优势：Http-Only Cookie能有效防范XSS攻击，比localStorage更安全，前端只需维护Bearer令牌即可。

4. 谨慎延长令牌有效期 #

• 适用场景：内部后台、低风险业务场景。
• 实现方式：修改config/sanctum.php中的expiration配置，将默认的60分钟（1小时）调整为更长时间（比如1440分钟=24小时）。
• 注意：有效期越长，令牌被盗后的风险越高，不建议对外公开的高风险系统使用此方案。

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