雷池 sl_portal_jwt 令牌过期后为何无法自动刷新？

Question

雷池（SafeLine）WAF 的 `sl_portal_jwt` 是用于 Portal 管理后台身份认证的 JWT 令牌，其过期后无法自动刷新，常见原因在于：雷池 Portal 前端未实现标准的“双 Token”机制（即 access_token + refresh_token），也未在 HTTP 401 响应时主动调用 `/api/v1/auth/refresh` 类接口（该接口实际未开放或未启用）；同时后端未配置 JWT 自动续期策略（如滑动过期、静默刷新），且前端 Axios/Fetch 拦截器缺失对 `exp` 字段的预判校验与透明续签逻辑。此外，部分部署场景下 Nginx 反向代理缓存了 401 响应，或浏览器 Cookie 的 `HttpOnly` 属性阻断了 JS 对刷新凭证的访问，进一步导致会话中断后必须手动重新登录。该设计虽提升了安全性，但牺牲了用户体验，需通过定制化开发补充刷新流程。

Answer 1

```html

一、现象层：用户侧可感知的会话中断行为

运维人员或安全工程师在雷池（SafeLine）Portal 管理后台操作约30–60分钟后，页面突然跳转至登录页，控制台可见大量 401 Unauthorized 响应；F12 Network 面板中 /api/v1/xxx 接口批量失败，但无任何自动重试或静默续签动作。此为 sl_portal_jwt 过期后“零感知断连”的典型表征。

二、协议层：JWT 标准机制与雷池实际实现的偏差

• 标准双 Token 模式：access_token（短期，15–30min） + refresh_token（长期，7–30天，HttpOnly+Secure）
• 雷池现状：仅颁发单个 sl_portal_jwt（默认有效期 3600s），Payload 中含 "exp": 1717028340，但无 refresh_token 字段，且 /api/v1/auth/refresh 路由返回 404 或 405
• 后果：无法满足 RFC 7519 §4.1.4 的续期语义，前端失去服务端协同刷新能力

三、架构层：前后端职责缺失与链路阻断点分析

环节	问题定位	技术证据
前端拦截器	Axios 未注入 exp 预校验逻辑	JWT 解析后未比对 Date.now() > payload.exp * 1000 - 60000（提前1分钟触发刷新）
Nginx 反向代理	缓存了 401 响应	proxy_cache_valid 401 1m; 导致错误响应被复用
浏览器 Cookie	sl_portal_jwt 设为 HttpOnly	JS 无法读取 token 内容，exp 字段不可预判

四、工程层：可落地的定制化刷新方案（含代码片段）

需在 Portal 前端构建轻量级刷新中间件：

// utils/jwtRefresh.js
export const setupJwtRefresh = () => {
  axios.interceptors.request.use(config => {
    const token = getCookie('sl_portal_jwt'); // 需后端开放非-HttpOnly 路径或改用 localStorage
    if (token) {
      const payload = JSON.parse(atob(token.split('.')[1]));
      if (Date.now() > (payload.exp * 1000 - 90000)) { // 提前90s触发
        return refreshAccessToken().then(newToken => {
          setCookie('sl_portal_jwt', newToken, { path: '/' });
          config.headers.Authorization = `Bearer ${newToken}`;
          return config;
        });
      }
    }
    return config;
  });
};

五、治理层：Nginx 与后端协同优化清单

1. 禁用 401 缓存：proxy_cache_bypass $http_authorization; proxy_no_cache $http_authorization;
2. 后端启用滑动过期：jwt.sign(payload, secret, { expiresIn: '30m', maxAge: '3600000' })
3. 开放 /api/v1/auth/refresh 接口，要求携带 X-Refresh-Token Header（从独立 Cookie 读取）
4. 将 sl_portal_jwt Cookie 属性调整为：Path=/; Max-Age=3600; Secure; SameSite=Lax

六、演进层：面向 SSO 与零信任的长期架构建议

graph LR
  A[Portal 前端] -->|OIDC Authorization Code Flow| B(Identity Provider)
  B -->|ID Token + Access Token| C[雷池后端]
  C -->|校验 JWT 并颁发 sl_portal_jwt| D[管理后台]
  D -->|定期调用 /oauth2/introspect| B
  style A fill:#4A90E2,stroke:#357ABD
  style B fill:#50C878,stroke:#2E8B57

通过集成 Keycloak 或 Authing 实现统一身份中枢，使 sl_portal_jwt 降级为短期会话凭证，彻底解耦认证生命周期与 Portal 自身会话策略。

```