Refresh Token介绍
上篇文章说到Token 是在服务端产生的。如果前端使用用户名/密码向服务端请求认证,服务端认证成功,那么在服务端会返回 Token 给前端。前端可以在每次请求的时候带上 Token 证明自己的合法地位,而Token的playload部分一般会存储相关的过期时间,一旦Token过期就会被网关拦截,因此如何设置Token刷新机制也是一个重点。
刷新Token探讨
- 过期时间尽量地短 ,过长的过期时间会让系统有长期暴露在接口的风险,理论上过期时间越短越好。但是过短的时间明显会带来不好的用户体验,想象下手机固定十秒钟就会锁屏一次。因此不能Token一过期就让用户重新登录,Token需要在后端或者前端动态刷新。
- 将Token存储在服务端 ,在服务器端保存 Token 状态,用户每次操作都会自动刷新(推迟) Token 的过期时间——Session 就是采用这种策略来保持用户登录状态的。然而仍然存在这样一个问题,在前后端分离、单页 App 这些情况下,每秒种可能发起很多次请求,每次都去刷新过期时间会产生非常大的代价。如果 Token 的过期时间被持久化到数据库或文件,代价就更大了。所以通常为了提升效率,减少消耗,会把 Token 的过期时保存在缓存或者内存中。
- 使用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标志