Token快过期的三种续期方案 - 详解

目录

滑动窗口机制 (Sliding Window Mechanism)

核心原理：

方案实现流程：

Java代码实现：

优点：

缺点：

双Token机制/刷新令牌机制（Refresh Token）

核心原理：

方案实现流程：

Java代码实现：

优点：

缺点：

服务端自动续期

核心原理：

方案实现流程：

Java代码实现：

优点：

缺点：

总结对比

---

用于实现Token续期的三大主流方案：滑动窗口机制、双Token/刷新令牌机制 (Refresh Token) 和 服务端自动续期。

滑动窗口机制 (Sliding Window Mechanism)

核心原理：

只要用户的Token在有效期内有活动，就会自动延长其Token过期时间

方案实现流程：

1. 用户发起请求的时候携带Token，后端校验Token的有效性及剩余时间
2. Token有效并且剩余时间低于阈值，后端生成新的Token（延长过期时间）
3. 返回响应数据和新的Token给前端，前端使用新的Token替换旧的Token
4. 若Token有效并且剩余时间高于阈值，返回正常响应数据，更换Token

Java代码实现：

@RestController
@Slf4j
public class AuthController {/*** Token过期时间（毫秒）*/private static final long ACCESS_TOKEN_EXPIRATION_TIME = 30 * 60 * 1000; // 30分钟/*** 续期阈值（毫秒）*/private static final long RENEWAL_THRESHOLD = 5 * 60 * 1000; // 5分钟内触发续期/*** 密钥*/private static final String SECRET = "PXrQbuCwXwOZzkML/Vm2S5rSwt1iybvmKtGDzVEu+Hc=";/*** 检查并续期Token* 如果传入的Token即将过期（剩余时间小于等于续期阈值），则生成一个新的Token返回；* 否则返回成功的响应，表示Token仍然有效。** @param token 请求头中的Authorization字段，即原始Token* @return Result 响应结果，若需要续期则返回新的Token，否则返回空的成功结果*/@GetMapping("/api/token")public Result register(@RequestHeader("Authorization") String token) {//1. 基础校验if (token == null) {return Result.error(ResultCode.UNAUTHORIZED); // 401 未授权}//2. 验证tokenAlgorithm algorithm = Algorithm.HMAC256(SECRET);DecodedJWT decodedJWT = JWT.require(algorithm).build().verify(token);Date expirationDate = decodedJWT.getExpiresAt();long currentTime = System.currentTimeMillis();long timeUntilExpiry = expirationDate.getTime() - currentTime;// 判断是否需要续期：当剩余有效时间小于等于设定阈值时if (timeUntilExpiry <= RENEWAL_THRESHOLD) {// 生成新的TokenString newToken = generateToken(decodedJWT.getClaim("userId").asString());return Result.success(newToken);}return Result.success();}/*** 根据用户ID生成新的JWT Token** @param userId 用户唯一标识* @return 新生成的JWT Token字符串*/private String generateToken(String userId) {Date now = new Date();Date expirationDate = new Date(now.getTime() + ACCESS_TOKEN_EXPIRATION_TIME); // 过期时间为30分钟return JWT.create().withIssuer("your_issuer").withIssuedAt(now).withExpiresAt(expirationDate).withClaim("userId", userId).sign(Algorithm.HMAC256(SECRET));}
}

优点：

• 用户体验佳：用户在持续操作的时候，完全感知不到登录状态的中断，体验非常流畅。
• 实现相对简单：逻辑清晰，代码改动小，易于集成到现有系统中。

缺点：

• 安全性低：如果用户的Token被窃取，攻击者只要持续发起请求，就可以让这个Token“永不过期”，大大增加了被滥用的风险。
• 难以控制最大会话时长：虽然每次都在续期，但很难限制一个会话的绝对最大生命周期（比如用户登录后必须24小时后强制重新登录）。

双Token机制/刷新令牌机制（Refresh Token）

此方案为业界最为主流、最推荐的方案，安全性高

核心原理：

此方案引入两种不同生命周期的Token

• Access Token (访问令牌)：

• • 生命周期短，一般为15分钟-2小时
  • 每次请求API的时候都会带在Authorization头中
  • 包含用户部分身份信息，用于快速校验

• Refresh Token (刷新令牌):

• • 生命周期长，一般7天-30天
  • 不用于访问API，仅用于获取新的Access Token。
  • 需要搭配服务端的Redis进行使用，用于校验其有效性。

方案实现流程：

1. 用户发起登录请求，后端校验用户相关信息，若成功，后端生成Access Token和Refresh Token返回给前端，并且将Refresh Token存储到redis中用于后续的校验
2. 用户再次请求服务端的时候，用户需要携带Access Token，若后端校验成功，那么成功响应或者继续处理；后端校验失败，返回401
3. 用户端携带Refresh Token调用refresh接口，验证Refresh Token有效性及匹配性
4. Refresh Token有效并且匹配，后端生成新的Access Token和新的Refresh Token，删除旧的Refresh Token，并且存储新的Refresh Token；后端执行成功，返回新的Access Token 和Refresh Token；若Refresh Token无效，则返回错误信息
5. 后续用户端请求的时候使用新的Access Token重新发起之前失败的请求

Java代码实现：

• 注意：此处的代码是经过业务封装后的代码，大家关注业务逻辑即可，不必关注详细的实现细节

@RestController
@Slf4j
@RequiredArgsConstructor
@RequestMapping("/api/v1/auth")
public class AuthController {private final JwtUtil jwtUtil; // jwt实现类/*** 刷新refreshToken** @param refreshTokenRequest refreshToken* @return refreshTokenResponse*/@GetMapping("/refreshToken")public Result refreshToken(@RequestBody @Valid RefreshTokenRequest refreshTokenRequest) {log.info("刷新token, refreshToken:{}",refreshTokenRequest.getRefreshToken());if (refreshTokenRequest.getRefreshToken() == null || refreshTokenRequest.getRefreshToken().isEmpty()){log.info("refreshToken为空或者不存在");return Result.error(ResultCode.UNAUTHORIZED);}//1. 从refreshToken中获取用户名String username = jwtUtil.extractUsernameFromToken(refreshTokenRequest.getRefreshToken());if (username == null || username.isEmpty()){log.info("refreshToken无效，此处无法提取出用户名");return Result.error(ResultCode.TOKEN_INVALID);}//3. 校验refreshTokenif (!jwtUtil.validateRefreshToken(refreshTokenRequest.getRefreshToken())){log.info("校验refreshToken失败:refreshToken{}", refreshTokenRequest.getRefreshToken());return Result.error(ResultCode.UNAUTHORIZED);}//4. 重新生成token和refreshTokenString newToken = jwtUtil.generateToken(username);String newRefreshToken = jwtUtil.generateRefreshToken(username);log.info("刷新token成功,newToken:{}, newRefreshToken:{}", newToken, newRefreshToken);return Result.success(RefreshTokenResponse.builder().token(newToken).refreshToken(newRefreshToken).build());}
}

优点：

• 高安全性：Access Token 寿命比较短，即使暴露危害相对较小
• 灵活性高：可以精确控制 Access Token 和 Refresh Token 的生命周期。

缺点：

• 实现复杂度高：需要管理两种Token，需要额外的存储（如Redis）来维护 Refresh Token 的状态。
• 增加网络请求：当 Access Token 过期时，需要先请求一次刷新接口，再重试原请求。

服务端自动续期

核心原理：

此方案和滑动窗口方案有类似之处，但是此方案更侧重于服务端主动管理和维护会话状态。并且此处的服务端自动续期是有状态的，依赖redis等存储来维护会话。然而滑动窗口方案是无状态的，只需要依赖Token本身即可。

方案实现流程：

Java代码实现：

优点：

• 控制力强：管理员可以完全掌控所有会话的状态。
• 安全性相对较高：可以实现强制下线、多端登录限制等功能。
• 可审计：所有会话活动都有记录。

缺点：

• 性能开销大：每次请求都需要查询和更新Redis，对数据库压力大。
• 系统复杂性高：需要维护会话存储和清理机制。
• 违背JWT无状态原则：JWT的设计初衷是无状态，此方案使其变为有状态，失去了部分优势。

总结对比

特性	滑动窗口机制	双Token/刷新令牌	服务端自动续期
用户体验	⭐⭐⭐⭐⭐ (最佳)	⭐⭐⭐⭐ (良好)	⭐⭐⭐⭐ (良好)
安全性	⭐⭐ (较低)	⭐⭐⭐⭐⭐ (最高)	⭐⭐⭐⭐ (高)
实现复杂度	⭐⭐ (简单)	⭐⭐⭐⭐ (复杂)	⭐⭐⭐⭐⭐ (最复杂)
服务器开销	⭐⭐⭐ (中等)	⭐⭐⭐ (中等)	⭐⭐ (高)
是否无状态	是	否 (Refresh Token需存储)	否
主流推荐度	低	高	中