关于token续签

通常我们会对token设置一个有效期，于是，就有了token续签的问题。由于token并没有续时机制，如果不能及时的替换掉过期的token，可能会拦截用户正常的请求，用户只能重新登录，如果提交的信息量很大，会给用户带来很不愉快的用户体验

续签方法

在token快过期时返回一个新的token
用户每次进入系统时刷新token，比如小程序登录
采用refreshToken机制
token里存储了用户的权限，当用户状态发生改变时

在token快过期时返回新的token

在服务器端可以校验即将过期的token，比如将token存在于redis中，可以用token的TTL去获取token的过期时间，如果时间比较短，就可以顺便返回一个新的token，这种方式对于前后端都不友好，客户端和服务端都需要去判断逻辑，会带来很大的性能损耗。

用户每次进入系统时刷新token

这种场景比较适用于小程序，可以在用户每次进入小程序时就去返回一个新的token，只要token的有效时间合适，是一个不错的选择方案

refreshToken机制

refreshToken是token的另一种延申

用户登录成功后返回两个 token ：一个是 acessToken ，它的过期时间可以比较短，比如是1天；另外一个是 refreshToken 它的过期时间更长一点，比如3天。
当客户端登录后，将 accessToken和refreshToken 保存在客户端本地，每次访问将 accessToken 传给服务端。服务端校验 accessToken 的有效性，如果客户端收到token过期的话，就将 refreshToken 传给服务端。
服务端 验证refreshToken 是否有效，若有效服务端就生成新的 accessToken和refreshToken 给客户端。否则，客户端就需要重新登录
这种方式可以减少用户进行账号密码登录的次数，但也会带来一些盗用和过期的风险，我们可以从以下几个方面去优化
性能优化
我们可以将其直接保存在数据库中，只会在客户端得到token过期时才会向服务器端发起请求
安全优化
只有在需要续签的时候才会带上，每个refreshToken只会被使用一次，当refreshToken被获取时，不会被大量滥用
可以设置refreshToken的生成机制，与客户端client_id绑定，设置独立的secret，在验证有效性时，会对比登录时的客户端client_id,相对安全
可用性优化
客户端可以设置定时器，在accessToken 快过期的时候，提前去通过 refreshToken 获取新的accessToken，防止出现短暂的token不可用
refreshToken是一种很好的方案进行JWT续签，与 OAuth2.0中的刷新机制类似