在现代 SaaS 平台的前后端分离架构中，基于 Token 的无状态（Stateless）认证是主流选择，其中 JSON Web Token (JWT) 被广泛应用。用户登录验证通过后，服务器利用加密算法（如 HMAC-SHA256）签发包含用户标识与权限角色的 JWT 字符串。前端保存该字符串后，后续请求只需将其置于请求头中，服务端通过校验数字签名即可确认用户身份，降低了数据库的查询压力。
然而，传统的单 JWT 方案存在一个明显的架构局限：JWT 自身的自包含特性使得它在签发后、过期之前，服务端难以通过简单的方式主动将其吊销（Revoke）。
短期凭证的体验挑战
为了防范由于 Token 泄露或人员权限变更造成的越权访问，安全规范通常会严格限制 JWT 的有效时长，例如强制设定为不超过 2 小时。
这种安全策略在实际业务中往往会对操作体验带来挑战。以心理机构的业务场景为例，当咨询师在系统中编辑一份长篇的心理评估报告时，操作过程可能持续数小时。如果恰好在编写中途 Token 达到了过期时间，当咨询师点击保存时，后端的鉴权接口将校验失败并返回 401 Unauthorized 状态码。若前端逻辑处理不够细腻，可能会直接清空当前状态并将用户强制重定向至登录页面，导致未保存的表单数据全部丢失，造成严重的体验问题。
双 Token 认证架构引入
为平衡严格的安全要求与持续的业务操作体验，目前业界通常采用双 Token 机制。橙星云在构建前后端鉴权体系时，也在登录环节引入了 Access Token 与 Refresh Token 的组合方案。
- Access Token（访问令牌）：有效生命周期较短（如 30 分钟），用于日常的业务 API 请求。即使发生泄露，影响窗口期也非常有限。
- Refresh Token（刷新令牌）：有效生命周期较长（如 7 天），它的唯一职责是在 Access Token 过期时，向特定授权接口申请换取新的 Access Token。前端会将其保存在安全的存储介质中，并不参与常规的业务数据请求。
基于请求拦截器的无感知续期
这一机制的核心落地在于前端 HTTP 客户端（如 Axios）的请求拦截器逻辑实现。
当业务操作携带已过期的 Access Token 发起请求并接收到后端的 401 状态码时，前端拦截器可以接管这一异常，执行自动续期流程：
- 拦截器捕获该错误，将当前因认证失败而中断的业务请求暂时挂起，存入一个请求重试队列。
- 在后台发起独立的刷新请求，携带本地的 Refresh Token 访问服务端的续期接口。
- 服务端校验 Refresh Token 的合法性（必要时可结合 Redis 黑名单等校验机制），核验通过后签发全新的 Access Token。
- 前端接收到新 Token 后，将其更新至全局配置，随后遍历并重试此前挂起在队列中的所有业务请求。
在整个执行周期中，凭证的过期判断、刷新获取以及请求的挂起重发，完全在底层网络交互层面自动完成。用户在前端界面上能够顺畅地提交数据，感受不到底层鉴权凭证的更替，从而实现了业务连续性与无感知刷新的最佳实践。