4. JWT 安全加固：强密钥策略、算法白名单、过期时间设置、刷新令牌机制

在压测场景中，JWT 的安全漏洞往往成为性能瓶颈的放大器。弱密钥导致令牌被伪造、算法混淆攻击绕过校验、过期时间过长引发令牌泄露风险、缺乏刷新机制造成频繁登录——这些问题在压测高并发下会集中暴露。本章从四个核心维度构建 JWT 安全防线，确保压测环境下的认证体系既安全又高效。

4.1 强密钥策略：从随机性到轮换周期

密钥是 JWT 签名的根基。压测中若使用弱密钥（如 secret123），攻击者可在毫秒级完成暴力破解，进而伪造任意令牌压垮后端。强密钥策略需覆盖生成、存储、轮换三个环节。

4.2 算法白名单：阻断算法混淆攻击

算法混淆攻击（Algorithm Confusion）是 JWT 最危险的漏洞之一。攻击者将头部 alg 从 RS256 篡改为 HS256，若服务端未校验算法类型，就会用公钥（公开字符串）作为 HMAC 密钥直接验证，从而伪造任意令牌。

防御方案：在服务端维护一个显式的算法白名单，并在验证前强制匹配。

// 算法白名单示例（Node.js + jsonwebtoken）
const ALLOWED_ALGORITHMS = ['RS256', 'ES384']; // 仅允许非对称算法

const verifyOptions = {
  algorithms: ALLOWED_ALGORITHMS,
  issuer: 'https://api.example.com',
};

jwt.verify(token, publicKey, verifyOptions, (err, decoded) => {
  if (err) {
    // 算法不在白名单或签名无效
    return res.status(401).json({ error: 'Invalid token' });
  }
  // 正常处理
});

4.3 过期时间设置：平衡安全与压测连续性

过期时间（exp）直接影响压测场景的令牌生命周期管理。设置过短会导致压测中令牌频繁过期，增加刷新请求量；设置过长则放大令牌泄露风险。

在压测脚本中，建议将 exp 设置为压测开始时间 + 固定时长，避免因系统时间偏差导致令牌提前过期。

// 生成压测用令牌示例
const now = Math.floor(Date.now() / 1000);
const payload = {
  sub: 'user_001',
  iat: now,
  exp: now + 900, // 15 分钟
  scope: 'read:orders write:orders',
};

4.4 刷新令牌机制：无感续期与安全隔离

刷新令牌（Refresh Token）是解决短期 access_token 频繁过期的标准方案。在压测中，刷新令牌的设计直接影响认证链路的吞吐量。

4.4.1 双令牌模型

• Access Token：短期（15 分钟），携带用户身份和权限，在请求头中传输。
• Refresh Token：长期（7 天），仅用于换取新的 Access Token，存储在安全存储（如 HttpOnly Cookie）。

4.4.2 刷新流程

1. 客户端检测 Access Token 即将过期（如提前 30 秒）。
2. 客户端携带 Refresh Token 请求 /auth/refresh 接口。
3. 服务端验证 Refresh Token 有效性（签名、过期、吊销状态）。
4. 服务端签发新的 Access Token（和可选的新的 Refresh Token）。
5. 客户端更新本地令牌，继续发起业务请求。

4.5 综合加固清单与压测验证

以下清单覆盖了 JWT 安全加固的全部关键点，压测团队应逐项验证。