1. 单token存在的问题
在正常的业务中，我们经常用到JWT生成单token进行后续的请求验证，但该模式有没有存在什么问题吗？
其实是有问题的，主要是token有效期设置长短的问题，如果设置的比较短，用户会频繁的登录，如果设置的比较长，会不太安全，因为token一旦被黑客截取的话，就可以通过此token与服务端进行交互获取数据了。
另外一方面，token是无状态的，也就是说，服务端一旦颁发了token就无法让其失效（除非过了有效期），这样的话，如果我们就算检测到token异常也无法使其失效，所以这也是无状态token存在的问题。
为了解决此问题，我们将采用 “双token三验证” 的解决方案来解决此问题。
2. 方案原理
为了解决单token模式下存在的问题，所以我们可以通过【双token三验证】的模式进行改进实现，主要解决的两个问题如下：
● token有效期长不安全
○ 登录成功后，生成2个token，分别是：access_token、refresh_token，前者有效期短（如：5分钟），后者的有效期长（如：24小时）
○ 正常请求后端服务时，携带access_token，如果发现access_token失效，就通过refresh_token到后台服务中换取新的access_token和refresh_token，这个可以理解为token的续签
○ 以此往复，直至refresh_token过期，需要用户重新登录
● token的无状态性
○ 为了使token有状态，也就是后端可以控制其提前失效，需要将refresh_token设计成只能使用一次
○ 需要将refresh_token存储到redis中，并且要设置过期时间
○ 这样的话，服务端如果检测到用户token有安全隐患（如：异地登录），只需要将refresh_token失效即可
流程详细如下：
用大白话来说就是这样的：
用户登录成功后，会生成两个token，一个短token，设置5分钟，一个长token，设置24小时，将其都传给前端，其中长token存储到Redis缓存中。然后在后续的请求中会携带短token进行验证，这是第一次校验。如果短token失效了，则会返回401，并通过长token到后台服务器中请求换取新的一对短token和长token，可以看做是token的续签，后端会校验长token的有效性，这是第二次检验。如果长token校验失败，则需要用户重新登录，如果有效的话，那么会去Redis就行查询，这是第三次验证、若未查到或查询失败，用户重新登录，若查到了，则会刷新一对短token，长token，并删除Redis里的旧数据，存储新的长token，短token继续用于请求的校验。这就是大致的流程，解决了单token可能存在的问题，就是别人就算拿到了短token，也是暂时的，不久就会进行一个长token的校验，还是得重新登陆。至于为什么将长token在Redis里面只存一次，是我们为了使token变为有状态，也就是可以提前失效，若黑客也拿到了长token进行频繁请求，也会使其失效，重新登陆。
3. 代码实现
3.1 生成刷新token
在单token生成基础上，再生成刷新refresh_token的主要逻辑有两点：
● 生成jwt格式的token，有效期时间一般小时为单位
● 将token存入到redis，使token有状态，并且确保只能使用一次
public static final String REDIS_REFRESH_TOKEN_PREFIX = "CUSTOMER_REFRESH_TOKEN_";
@Override
public String createRefreshToken(Map<String, Object> claims) {
//生成长令牌的有效期时间单位为：小时
Integer ttl = jwtProperties.getRefreshTtl();
String refreshToken = JwtUtils.createToken(claims, jwtProperties.getPrivateKey(), ttl);
//长令牌只能使用一次，需要将其存储到redis中，变成有状态的
String redisKey = this.getRedisRefreshToken(refreshToken);
this.stringRedisTemplate.opsForValue().set(redisKey, refreshToken, Duration.ofHours(ttl));
return refreshToken;
}
private String getRedisRefreshToken(String refreshToken) {
//md5是为了缩短key的长度
return REDIS_REFRESH_TOKEN_PREFIX + SecureUtil.md5(refreshToken);
}
测试用例：
@Test
void createRefreshToken() {
Map<String, Object> claims = MapUtil.<String, Object>builder().put("id", 123)
.build();
String refreshToken = this.tokenService.createRefreshToken(claims);
System.out.println(refreshToken);
}
3.2 刷新token
刷新token的动作是在refresh_token过期之后进行的，主要实现关键点有：
● 校验refresh_token是否被伪造以及是否在有效期内
● 从redis中查询，是否不存在，如果不存在说明已经失效或已经使用过，如果存在，就需要将其删除
● 重新生成一对token，响应结果
@Override
public UserLoginVO refreshToken(String refreshToken) {
if (StrUtil.isEmpty(refreshToken)) {
return null;
}
Map<String, Object> originClaims = JwtUtils.checkToken(refreshToken, this.jwtProperties.getPublicKey());
if (ObjectUtil.isEmpty(originClaims)) {
//token无效
return null;
}
//通过redis校验，原token是否使用过，来确保token只能使用一次
String redisKey = this.getRedisRefreshToken(refreshToken);
Boolean bool = this.stringRedisTemplate.hasKey(redisKey);
if (ObjectUtil.notEqual(bool, Boolean.TRUE)) {
//原token过期或已经使用过
return null;
}
//删除原token
this.stringRedisTemplate.delete(redisKey);
//重新生成长短令牌
String newRefreshToken = this.createRefreshToken(originClaims);
String accessToken = this.createAccessToken(originClaims);
return UserLoginVO.builder()
.accessToken(accessToken)
.refreshToken(newRefreshToken)
.build();
}
然后完善一下controller和service层接口的代码：
// controller层
/**
* 刷新token，校验请求头中的长令牌，生成新的长短令牌
*
* @param refreshToken 原令牌
* @return 登录结果
*/
@PostMapping("/refresh")
public R<UserLoginVO> refresh(@RequestHeader(Constants.GATEWAY.REFRESH_TOKEN) String refreshToken) {
return R.success(this.memberService.refresh(refreshToken));
}
// service层
@Override
public UserLoginVO refresh(String refreshToken) {
return this.tokenService.refreshToken(refreshToken);
}
最后，在你写的单token基础上添加上上述的逻辑，在返回的实体类中额外加上refresh_token 值，这样会得到下面的测试结果：
可以看到已经返回了两个token。这样基本上实现了双token三验证的功能。