Token刷新策略

刷新Token的方法

安全性较低

前端判断过期时间

1. 每次请求时，判断token是否临期。
2. 如果临期，则调用后端请求刷新token接口。
3. 后端返回新token后，用新token替换旧token。
4. 继续请求原始接口。

此方案缺点：

1. 前后端时间可能存在偏差
2. 前端的时间可能被篡改
3. token直接存在前端，会被浏览器插件和脚本获取
4. token传输过程中被绑架，然后直接调用后台数据

后端判断过期时间

1. 前端每次请求时都会带着token请求
2. 后端在收到请求后，判断token是否过期。
3. 如果过期，则返回401状态码。
4. 前端接收到401状态码后，调用后端请求刷新token接口。
5. 后端返回新token后，用新token替换旧token。
6. 继续请求原始接口。

缺点：

1. 只有一个token，一泄露就会被人用来访问资源
2. 多个并发请求可能导致token刷新冲突，例如，两个接口都401，然后会刷新两个token，然后token就会覆盖了。

安全性高

双token机制

1. 后台生成两个token，一个access_token，一个refresh_token。前者用来访问资源，后者用来刷新access_token。
2. 前端每次请求，携带access_token。
3. 后端在收到请求后，判断access_token是否过期。
4. 如果过期，则判断refresh_token是否过期。
5. 如果refresh_token也过期，则返回401状态码。
6. 如果refresh_token未过期，则调用刷新token接口，返回新的access_token。
7. 前端接收到新token后，用新token替换旧token。
8. 继续请求原始接口。
9. Refresh Token是滑动过期策略，即只要用这个Refresh Token访问刷新接口，就会使这个Refresh Token的过期时间延长。如果一段时间内，用户没有使用这个，那么refresh_token也会过期。
   缺点：
10. refresh_token需要保存在服务器，且不能被恶意用户访问。