双token三验证（Refresh Token 机制​）

单token存在的问题

        我们都知道，token是我们在前后端数据传输的时候为了保证安全从而必须需要进行设置的东西，他的主要作用实际上就是为了保证我们的数据安全，进行身份验证和授权，并且相对于session而言更加适合如今的分布式系统，但是，token本身是无状态的，无法动态设置能不能使用，也就是说任何人获得了当前的token就能够利用token进行网络攻击，例如多台ip设备并发攻击当前网站等，下面列出传统的解决方案

解决

给token设置一个过期时间，例如jwt生成的token实际上是可以设置时间的，当时间过期之后当前token就无法进行使用了，可以有效的避免因泄露造成的安全，但是，这样就会出现一个问题，时间应当设置多少，如果设置的比较短，用户会频繁的登录，如果设置的比较长，会不太安全，为了解决这个问题，我们采取【双token三验证】的解决方案来解决这个问题

方案原理

token有效期长不安全

        登录成功之后，生成两个token，分别是access_token,和refresh_token,前者有效期可以较短，后者有效期可以较长

        正常请求后端服务的时候，携带access_token，如果发现access_token失效，就通过refresh_token到后台去获取新的access_token和refresh_token，你可以理解为token的续表，

        以此往复，直到refresh_token过期重新登录即可

token的无状态性

        为了使token有状态，也就是我们可以控制token的什么时候失效，我们可以将refresh_token设置为只能够使用一次

        那么这个时候就需要将refresh_token存储到redis中，并且设置过期时间

        当我们检测到token异常的时候，就可以直接令refresh_token失效即可

具体流程

1.前端将用户名和密码给予我们的时候，我们判断是否合理，然后生成access_token以及refresh_token即可

2.refresh_token和access_token可以都是jwt生成，但是，要注意，access_token的时间要短一下，refresh_token的时间要长一下，并且，refresh_token的有效时间并非是由jwt控制的，而是我们的redis存入的时候进行控制的，这也是为了使得token具有有效性，

3.将a_token和r_token返回前端即可

4.当登录成功之后再次发出请求，这一次可以仅仅返回access_token也就是那个时间比较短的token，然后我们进行校验，如果当前的access_token合理，返回响应结果即可，也就是第一次验证

5.如果access_token不合理，那我们返回401，让前端返回refresh_token,我们检验这个token是否有效，无效返回重新登录，有效继续，也就是第二次验证

6.我们查询redis中当前的refresh_token,看看是否存在和使用过，如是是，返回错误，不是的话就去删除旧的token生成新的access_token和refresh_token

7.循环往复

这样就解决了token的无状态性带来的问题。/