JWT 过期后 自动刷新方案

JWT（JSON Web Token）广泛应用于现代 Web 开发中的认证与授权，它以无状态、灵活和高效的特点深受开发者欢迎。然而，JWT 的一个核心问题是 Token 过期后如何处理。本文将总结常见的解决方案，分析其优缺点，并帮助开发者选择适合自己项目的方案。

JWT 过期问题的挑战

1. 安全性：如果 Token 长时间有效，泄露后可能导致严重的安全问题；短时间有效则需要频繁刷新。
2. 无状态性：JWT 通常是无状态的，如何在不依赖后端存储的情况下管理过期 Token 成为难点。
3. 刷新机制：如何设计高效、安全的 Token 刷新机制，避免用户频繁登录体验不佳。

解决方案

方案一：双 Token 模式（Access Token + Refresh Token）

设计思路

• 使用两个 Token：
  1. Access Token：短生命周期（如 15 分钟）。
  2. Refresh Token：长生命周期（如 7 天）。
• 客户端使用 Access Token 请求资源；当 Access Token 过期时，使用 Refresh Token 获取新的 Access Token 和 Refresh Token。

优点

• 高安全性：Access Token 即使泄露，时间窗口较短，风险可控。
• 客户端和服务器可以协同管理 Refresh Token，有效防止重复使用攻击。

缺点

• 客户端实现复杂度较高，需要管理两个 Token。
• 需要额外的接口和逻辑处理 Refresh Token。

适用场景

• 对安全性要求较高的系统，如金融、支付平台。

核心代码

后端接口验证 Refresh Token 并生成新 Token：

@PostMapping("/refresh-token")
public ResponseEntity<?> refreshToken(@RequestBody Map<String, String> tokens) {
    String refreshToken = tokens.get("refreshToken");

    if (!jwtUtil.checkToken(refreshToken)) {
        return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body("Invalid Refresh Token");
    }

    Map<String, String> claims = jwtUtil.decode(refreshToken);
    String newAccessToken = jwtUtil.generateJwtToken(claims.get("username"), claims.get("userId"));
    String newRefreshToken = jwtUtil.generateRefreshToken(claims.get("username"), claims.get("userId"));

    return ResponseEntity.ok(Map.of("accessToken", newAccessToken, "refreshToken", newRefreshToken));
}

方案二：固定 Session ID + Token

设计思路

• 后端生成唯一的 Session ID 并与 Token 关联，将会话信息（如 Token 状态、用户信息）存储到 Redis 或数据库。
• 客户端请求时，携带 Session ID 和 Token，后端验证会话状态和 Token。

优点

• 可灵活控制会话状态，支持主动使某些 Session 失效。
• 后端可以精细化管理 Token 状态，无需频繁解析 JWT 签名。

缺点

• 依赖 Redis 或数据库存储会话信息，增加系统复杂度。
• 不完全无状态，分布式部署时需要额外处理会话同步。

适用场景

• 用户登录频繁、对会话状态要求高的系统。

核心代码

// 从 Redis 获取会话信息并验证 Token
SessionInfo sessionInfo = redisUtil.get("session_" + sessionId, SessionInfo.class);
if (sessionInfo == null || !sessionInfo.getToken().equals(token)) {
    return ResponseEntity.status(HttpStatus.UNAUTHORIZED).body("Session Invalid");
}

// Token 过期时刷新
if (jwtUtil.isTokenExpired(token)) {
    String newToken = jwtUtil.generateJwtToken(sessionInfo.getUsername(), sessionInfo.getUserId());
    sessionInfo.setToken(newToken);
    redisUtil.set("session_" + sessionId, sessionInfo);
    return ResponseEntity.ok(Map.of("newToken", newToken));
}

方案三：Token 无状态 + 客户端定时刷新

设计思路

• Token 完全无状态，仅存储签名信息和过期时间。
• 客户端定期检查 Token 的有效期，并在即将过期时主动请求刷新。

优点

• 无需后端存储任何会话信息，完全无状态。
• 简单高效，适合分布式系统。

缺点

• 客户端需要管理 Token 刷新逻辑，增加复杂度。
• 无法主动失效某个用户会话（如强制下线）。

适用场景

• 轻量级或低安全需求的系统，如小型工具或内部系统。

核心代码

客户端定时检查并刷新：

function checkTokenExpiry() {
    const token = localStorage.getItem('accessToken');
    const payload = JSON.parse(atob(token.split('.')[1]));
    const expiryTime = payload.exp * 1000;

    if (Date.now() > expiryTime - 5 * 60 * 1000) { // 提前 5 分钟刷新
        refreshToken();
    }
}

function refreshToken() {
    const refreshToken = localStorage.getItem('refreshToken');
    fetch('/refresh-token', {
        method: 'POST',
        body: JSON.stringify({ refreshToken }),
        headers: { 'Content-Type': 'application/json' }
    })
    .then(response => response.json())
    .then(data => {
        localStorage.setItem('accessToken', data.accessToken);
        localStorage.setItem('refreshToken', data.refreshToken);
    });
}

方案四：Hybrid Token（混合 Token）

设计思路

• 将部分会话信息存储到 Token 中，而状态信息（如是否过期）存储在 Redis。
• Token 验证时仅检查无状态部分，必要时从 Redis 获取状态信息。

优点

• 兼顾无状态性和灵活性。
• 后端可动态管理会话状态，同时减少频繁访问存储。

缺点

• 实现较复杂，适合对性能要求较高的场景。

适用场景

• 高并发、大规模分布式系统，如社交平台、内容分发系统。

方案对比

结语

不同的方案适用于不同的场景，开发者在选择方案时需要考虑：

1. 安全性：是否需要强安全性保障，如支持主动失效。
2. 性能：是否需要减少后端存储依赖或高效处理。
3. 复杂度：是否愿意增加客户端和后端的实现复杂性。

在实际开发中，可以结合业务需求和技术条件选择最适合的方案，甚至进行多方案组合，实现性能与安全的平衡。