Refresh Token介绍

Refresh Token介绍

上篇文章说到Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证，服务端认证成功，那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位，而Token的playload部分一般会存储相关的过期时间，一旦Token过期就会被网关拦截，因此如何设置Token刷新机制也是一个重点。

刷新Token探讨

1. 过期时间尽量地短 ，过长的过期时间会让系统有长期暴露在接口的风险，理论上过期时间越短越好。但是过短的时间明显会带来不好的用户体验，想象下手机固定十秒钟就会锁屏一次。因此不能Token一过期就让用户重新登录，Token需要在后端或者前端动态刷新。
2. 将Token存储在服务端 ，在服务器端保存 Token 状态，用户每次操作都会自动刷新（推迟） Token 的过期时间——Session 就是采用这种策略来保持用户登录状态的。然而仍然存在这样一个问题，在前后端分离、单页 App 这些情况下，每秒种可能发起很多次请求，每次都去刷新过期时间会产生非常大的代价。如果 Token 的过期时间被持久化到数据库或文件，代价就更大了。所以通常为了提升效率，减少消耗，会把 Token 的过期时保存在缓存或者内存中。
3. 使用Refresh Token刷新 服务端不需要刷新 Token 的过期时间，一旦 Token 过期，就反馈给前端，前端使用 Refresh Token 申请一个全新 Token 继续使用。这种方案中，服务端只需要在客户端请求更新 Token 的时候对 Refresh Token 的有效性进行一次检查，大大减少了更新有效期的操作，也就避免了频繁读写。当然 Refresh Token 也是有有效期的，但是这个有效期就可以长一点了，比如，以天为单位的时间。refresh token，也是加密字符串，并且和token是相关联的。相比获取各种资源的token，refresh token的作用仅仅是获取新的token，因此其作用和安全性要求都大为降低，所以其过期时间也可以设置得长一些。

Refresh Token实现原理

• 在access_token里加入refresh_token标识，给access_token设置短时间的期限（例如一天），给refresh_token设置长时间的期限（例如七天）。当活动用户（拥有access_token）发起request时，在权限验证里，对于requeset的header包含的access_token、refresh_token分别进行验证：

• 1、access_token没过期，即通过权限验证；

• 2、access_token过期,refresh_token没过期，则返回权限验证失败，并在返回的response的header中加入标识状态的key，在request方法的catch中通过webException来获取标识的key，获取新的token（包含新的access_token和refresh_token），再次发起请求，并返回给客户端请求结果以及新的token，再在客户端更新公共静态token模型；

• 3、access_token过期,refresh_token过期即权限验证失败。

Refresh Token生成步骤

• 一： 生成Token时加入refresh token标志
• 二：在权限验证环节，对于access_token、refresh_token设置不同时间的期限。再根据判断结果返回状态。
• 三：生成Token时加入refresh token标志
• 四：生成Token时加入refresh token标志

具体代码格式与参考博客