Atopos

3.3.1 存储策略

Refresh Token 必须服务端存储。与 Access Token 不同，Refresh Token 需要支持主动吊销和单次使用，不能完全无状态。通常使用 Redis 存储：

1
// 生成 refreshToken 并存入 redis
2
const redisKey = `REFRESH_TOKEN_PREFIX_${md5(refreshToken)}`;
3
await redis.setex(redisKey, 7 * 24 * 3600, refreshToken);

前端存储方案因平台而异：

• Web 端：推荐使用 Secure + HttpOnly Cookie。这样 JavaScript 无法访问，有效防御 XSS 攻击，再配合 CSRF Token 防御跨站请求伪造。
• 移动端：使用平台安全存储 API——iOS 用 Keychain，Android 用 Keystore。
• 最安全架构：BFF（Backend for Frontend）模式——所有认证和 Token 处理都在后端完成，JWT 永远不会暴露给浏览器存储或 JavaScript 访问。

3.3.2 令牌轮换机制

每次使用 Refresh Token 换取新 Access Token 时，同时生成新的 Refresh Token，并立即使旧的 Refresh Token 失效。

1
async function rotateRefreshToken(oldRefreshToken) {
2
    // 验证旧 Refresh Token
3
    const decoded = await verifyRefreshToken(oldRefreshToken);
4
    // 使旧 Token 立即失效
5
    await revokeToken(oldRefreshToken);
6
    // 生成新 Token 对
7
    const newAccessToken = generateAccessToken(decoded.userId);
8
    const newRefreshToken = generateRefreshToken(decoded.userId);
9
    return { accessToken: newAccessToken, refreshToken: newRefreshToken };
10
}

轮换机制的核心安全收益：即便攻击者截获了 Refresh Token，也只能使用一次，因为第二次请求时该令牌已经被轮换掉了。

3.3.3 并发刷新冲突处理

轮换机制在多个客户端并发刷新时会产生“竞态条件”——客户端 A 和客户端 B 同时发起刷新请求，服务端处理了 A 的请求后，旧 Refresh Token 立即失效，导致 B 的请求失败并返回 invalid_grant 错误。

解决方案：

• 前端互斥锁：通过 refreshLock 标志确保同一时刻只有一个刷新请求在处理，其他请求等待锁释放后获取最新 Token。
• 服务端版本号：在 Refresh Token 中嵌入版本号字段，服务端验证版本号一致性，冲突时返回并发修改错误。

3.3.4 防盗检测

由于 Refresh Token 长期有效且权限大，需要增加额外的安全检测维度：

• 设备绑定：Refresh Token 与 deviceId 强关联，检测到跨设备使用则主动失效。
• IP 漂移检测：同一 Refresh Token 在短时间内出现 IP 地址变化时，触发安全警告或强制重新认证。
• 版本号机制：每次刷新时递增 token_version，服务端存储最新版本号，旧版本 Refresh Token 直接拒绝。

Header（头部）

1
{
2
    "alg": "HS256",
3
    "typ": "JWT"
4
}

最关键的安全陷阱：如果服务端直接信任 alg 字段而不做强制校验，攻击者可以将 alg 改成 none 来完全绕过签名验证。生产环境必须使用白名单机制，只允许白名单内的算法。

Payload（载荷）

Payload 存放实际的身份信息，不是加密的，只是 Base64 编码。任何人都可以解码看到原始内容。标准声明（Claims）包括：

业务自定义声明可以任意添加，但绝对不要放敏感信息（如密码、身份证号）——因为它们只是 Base64 编码，不是加密。

Signature（签名）

签名是 JWT 安全的核心。以 HS256 为例：

1
Signature = HMACSHA256(base64UrlEncode(Header) + '.' + base64UrlEncode(Payload), secretKey)

签名验证的核心在于 验证签名是否由合法密钥生成。常用算法分为两类：

• 对称算法（HS256）：单服务场景，加密解密用同一个密钥，简单但密钥分发困难。
• 非对称算法（RS256、ES256、EdDSA）：私钥签名、公钥验证，适合微服务架构和开放平台。

2025 年的安全趋势中，EdDSA（Ed25519）是推荐的首选算法，提供出色的性能和安全性；ES256（ECDSA with P-256）是优异的备选。HS256 仍可使用，但密钥至少要有 256 位的熵。

生成流程

1
// 生成 JWT（Node.js + jsonwebtoken 示例）
2
const jwt = require("jsonwebtoken");
3

4
const payload = {
5
    sub: "user123",
6
    name: "John Doe",
7
    role: "admin",
8
    iat: Math.floor(Date.now() / 1000),
9
    exp: Math.floor(Date.now() / 1000) + 15 * 60, // 15分钟后过期
10
    jti: uuidv4(),
11
};
12

13
const token = jwt.sign(payload, SECRET_KEY, { algorithm: "HS256" });

验证流程

验证签名只是第一步，完整的验证链条必须包含：

1
try {
2
    const decoded = jwt.verify(token, SECRET_KEY, {
3
        algorithms: ["HS256"],
4
        audience: "your-api-audience",
5
    });
6
    // 可选：额外校验 jti 是否在黑名单
7
    if (await isTokenRevoked(decoded.jti)) {
8
        throw new Error("Token has been revoked");
9
    }
10
} catch (err) {
11
    // 过期、签名错误、黑名单等情况统一拒绝访问
12
}

特殊优化：验证 exp 已过期但 orig_iat（原始签发时间）还在 MaxRefresh 窗口内的场景，可以进入刷新流程。

④ 四大安全隐患与应对

⑤ 存储安全：多端策略表格

⑥ 传输安全：HTTPS 是底线

在大多数实现中，JWT 作为 Bearer Token 使用——谁持有 Token 谁就能访问受保护资源。因此传输安全没有商量余地。没有 HTTPS，攻击者可以通过中间人攻击截获 Token 并冒充用户。