前言
今天我们来聊聊一个看似简单却让无数开发者栽跟头的问题------Token续期。
你以为Token续期只是重置时间?90%的系统安全漏洞由此而生!
当用户正在提交重要表单时突然跳转到登录页面,或者系统在高峰期因Token并发刷新而崩溃,这些问题的根源往往在于Token续期策略设计不当。
最近准备面试的小伙伴,可以看一下这个宝藏网站(Java突击队):www.susan.net.cn,里面:面试八股文、场景设计题、面试真题、项目实战、工作内推什么都有。
一、Token续期的本质
Token续期不是简单的时间重置,而是安全、用户体验和系统性能的三方博弈。
我们先看一个典型事故:
java
// 错误案例:简单过期的Token检查
public boolean validateToken(String token) {
return JwtUtil.getExpiration(token).after(new Date());
}
这种实现会导致:
- 用户操作中断(Token突然过期)
- 安全风险(旧Token继续有效)
- 并发问题(多个请求同时触发刷新)
Token续期的三大核心问题
- 何时续期:提前多久刷新最合理?
- 如何续期:单Token还是双Token?有状态还是无状态?
- 安全防控:如何防止令牌劫持和并发风暴?
下面我跟大家一起聊聊工作中最常用的5种主流方案,希望对你会有所帮助。
二、单Token方案
2.1 基础实现与致命缺陷
java
public String refreshToken(String oldToken) {
String username = JwtUtil.parseUsername(oldToken);
return JwtUtil.generateToken(username, 30 * 60); // 直接生成新Token
}
三大致命缺陷:
- 旧Token在有效期内依然可用(安全黑洞)
- 多个请求同时触发刷新会导致多个有效Token并存(并发灾难)
- 无法强制下线用户(状态失控)
2.2 黑名单优化方案

代码实现:
java
public String safeRefresh(String oldToken) {
// 旧Token加入黑名单(有效期比Token长5分钟)
redis.setex("blacklist:"+oldToken, "1", 35 * 60);
String username = JwtUtil.parseUsername(oldToken);
String newToken = JwtUtil.generateToken(username, 30 * 60);
return newToken;
}
适用场景:
- 内部低安全系统
- 短期活动页面
- 快速原型开发
三、双Token方案
3.1 核心架构设计

3.2 安全增强:三验证机制
java
public TokenPair refreshTokens(String refreshToken) {
// 1. JWT签名验证
if (!JwtUtil.verifySignature(refreshToken)) {
throw new SecurityException("非法令牌");
}
// 2. 状态令牌验证
String stateToken = extractStateToken(refreshToken);
if (!redis.exists("state_token:" + stateToken)) {
throw new SecurityException("令牌已失效");
}
// 3. 设备绑定验证
String deviceId = getDeviceIdFromRequest();
if (!deviceId.equals(redis.get("bind_device:" + stateToken))) {
throw new SecurityException("设备变更需重新登录");
}
return generateNewTokenPair(refreshToken);
}
3.3 并发控制:分布式锁方案
java
public TokenPair safeRefresh(String refreshToken) {
String lockKey = "refresh_lock:" + refreshToken;
RLock lock = redissonClient.getLock(lockKey);
try {
if (lock.tryLock(2, 5, TimeUnit.SECONDS)) {
return doRefresh(refreshToken);
}
throw new BusyException("系统繁忙,请重试");
} finally {
lock.unlock();
}
}
适用场景:
- 金融系统
- 电商平台
- 企业级应用
最近建了一些工作内推群,各大城市都有,欢迎各位HR和找工作的小伙伴进群交流,群里目前已经收集了不少的工作内推岗位。加苏三的微信:li_su223,备注:掘金+所在城市,即可进群。
四、自动续期方案
4.1 拦截器+滑动窗口

智能阈值计算:
java
public boolean shouldRenew(Token token) {
long remainTime = token.getExpireTime() - System.currentTimeMillis();
long totalTime = token.getTotalValidTime();
// 双阈值策略:绝对时间(5分钟)和相对时间(30%有效期)
return remainTime <= Math.min(5 * 60 * 1000, 0.3 * totalTime);
}
4.2 Redis缓存续期方案
java
public void autoRenewToken(String headerToken) {
String cacheKey = "token_cache:" + headerToken;
String cacheToken = redis.get(cacheKey);
if (cacheToken == null) throw new TokenExpiredException("令牌已完全过期");
if (JwtUtil.isAboutToExpire(cacheToken)) {
String newToken = generateNewToken();
// 关键:Token更新但缓存Key不变
redis.setex(cacheKey, newToken, 2 * 60 * 60);
response.setHeader("X-New-Token", newToken);
}
}
4.3 Gateway全局过滤器方案
java
@Component
@Order(-100)
public class TokenRenewFilter implements GlobalFilter {
@Override
public Mono<Void> filter(ServerWebExchange exchange, Chain chain) {
String token = extractToken(exchange.getRequest());
if (renewService.isRenewRequired(token)) {
String newToken = renewService.renewToken(token);
exchange.getResponse().getHeaders().set("X-New-Token", newToken);
}
return chain.filter(exchange);
}
}
适用场景:
- 微服务架构
- 前后端分离应用
- 高并发用户系统
五、分布式环境特殊挑战
5.1 多设备会话管理

设备冲突解决方案:
java
public void handleLogin(User user, String deviceType) {
String oldSessionKey = "user_devices:" + user.getId() + ":" + deviceType;
String oldToken = redis.get(oldSessionKey);
if (oldToken != null) {
redis.del("token_cache:" + oldToken); // 使旧Token失效
}
String newToken = generateToken();
redis.set(oldSessionKey, newToken);
}
5.2 跨服务令牌验证
java
public boolean validateTokenAcrossServices(String token) {
// 1. 本地快速验证
if (JwtUtil.verifyWithLocalKey(token)) return true;
// 2. 查询认证中心
return authCenterClient.validateToken(token);
}
六、五大方案对比
方案 | 安全性 | 用户体验 | 实现复杂度 | 适用场景 | 性能影响 | 典型应用 |
---|---|---|---|---|---|---|
单Token基础版 | ★☆☆☆☆ | ★★☆☆☆ | ★☆☆☆☆ | 内部测试系统 | 低 | 原型开发 |
单Token+黑名单 | ★★☆☆☆ | ★★★☆☆ | ★★☆☆☆ | 低风险Web应用 | 中 | 企业内网 |
双Token基础版 | ★★★☆☆ | ★★★★☆ | ★★★☆☆ | 常规Web/APP | 中 | 电商平台 |
双Token+三验证 | ★★★★★ | ★★★☆☆ | ★★★★☆ | 金融/支付系统 | 高 | 银行APP |
自动续期方案 | ★★★★☆ | ★★★★★ | ★★★★☆ | 高用户体验要求系统 | 中高 | SAAS应用 |
七、方案如何选型?

八、最佳实践与避坑指南
8.1 安全黄金法则
-
令牌时效控制:
- Access Token ≤ 30分钟
- Refresh Token ≤ 7天(需配合刷新次数限制)
-
敏感操作二次认证:
java
public void processSensitiveOperation(String token) {
if (isSensitiveOperation()) {
if (!smsVerifyService.verify(getCurrentUser())) {
throw new SecurityException("需要短信验证");
}
}
// 执行操作
}
8.2 性能优化关键
- 异步刷新队列:

- 本地缓存验证:
java
// 使用Caffeine实现本地缓存
LoadingCache<String, Boolean> tokenCache = Caffeine.newBuilder()
.maximumSize(10_000)
.expireAfterWrite(5, TimeUnit.MINUTES)
.build(key -> redis.exists("valid_token:" + key));
8.3 十大避坑指南
- 永远不要用长有效期的Access Token
- Refresh Token必须是一次性使用的
- 客户端必须实现静默更新机制
- 分布式环境下必须用RedLock处理并发刷新
- 敏感操作必须二次认证
- 黑名单有效期需长于Token有效期
- 设备变更必须重新认证
- 监控Refresh Token的使用频率
- 定期轮换签名密钥
- 实现令牌撤销接口
好的Token管理系统应该像人体的自主神经系统------平时感受不到它的存在,但在需要时总能及时响应。
最后说一句(求关注,别白嫖我)
如果这篇文章对您有所帮助,或者有所启发的话,帮忙关注一下我的同名公众号:苏三说技术,您的支持是我坚持写作最大的动力。
求一键三连:点赞、转发、在看。
关注公众号:【苏三说技术】,在公众号中回复:进大厂,可以免费获取我最近整理的10万字的面试宝典,好多小伙伴靠这个宝典拿到了多家大厂的offer。