关于不存储RefreshToken的实现方案，恳请您分享专业看法

你的这个思路其实是无状态JWT Refresh Token模式，从技术实现和测试结果来看，基础流程完全可行，还能带来不少明显优势：

方案核心优势 #

• 性能优化：正如你所说，直接通过签名校验和过期时间验证Token，省去了Redis/数据库的IO开销，高并发场景下能显著降低响应延迟
• 架构简化：不需要维护RefreshToken的存储、过期清理逻辑，减少系统依赖，部署和维护成本更低
• 基础流程验证充分：你已经测试Token重发和登出功能正常，说明核心身份流转逻辑是通顺的

需要注意的潜在风险 #

不过这个方案也存在几个无法忽视的局限性，可能在后续业务扩展或安全场景中暴露问题：

• 无法主动失效RefreshToken：服务器没有存储Token记录，即使用户执行登出操作，只要RefreshToken本身没过期，攻击者拿到它依然可以换取新的AccessToken。你测试的登出功能只是前端清除了Token，但后端没能力拦截恶意使用
• 泄露风险放大：一旦RefreshToken被窃取，攻击者能持续用它生成AccessToken，直到Token自然过期，期间你没办法提前终止它的效力
• 过期时间两难：如果把RefreshToken有效期设短，用户会频繁触发Token刷新，体验差；设长，泄露后的风险周期会被拉长
• Claims无法动态更新：如果用户权限、角色等信息变化，旧RefreshToken携带的Claims不会自动更新，必须等Token过期才能获取新信息

风险优化建议 #

如果你的业务场景对安全性要求不高（比如内部工具、低敏感应用），当前方案完全可以直接用；如果要兼顾性能和安全性，可考虑以下折中方案：

• 给RefreshToken添加唯一标识（jti），平时依然无状态校验，仅当需要主动失效（比如用户登出、账号异常）时，才将jti存入Redis黑名单，校验时额外检查黑名单
• 严格控制传输安全：必须用HTTPS，若通过Cookie传输，要设置HttpOnly、Secure、SameSite属性，防范XSS和CSRF攻击
• 搭配短有效期的AccessToken，即便AccessToken泄露，影响范围也能控制在较短时间内

附上你提供的解析Token代码：

private Claims getTokenBody(String token, Key secret) {
    try {
        return Jwts.parserBuilder()
                .setSigningKey(secret)
                .build()
                .parseClaimsJws(token)
                .getBody();

    } catch (ExpiredJwtException e) {
        throw new TokenExpiredException();

    } catch (JwtException e) {
        throw new TokenNotValidException();
    }
}

内容的提问来源于stack exchange，提问作者lohny