最近开始做新项目，是一个toC项目，之前的登录接口是一个实习生写的，偶然间另一位同事看了看项目代码之后跟我说为了提高安全性，修改了登录接口。。。
背景
博主在做的一个项目之前的登录接口是实习生写的，登录设计就是简单的提交用户名密码获取token，然后token的过期时间巨长是30天，于是乎另一位工作年限长一点的同事修改了代码，变成了登录获取两个token：
- 1.
accessToken: 真正用来获取数据的权限 - 2.
refreshToken: 用来获取accessToken
为什么需要双token?
总所周知，token是为了防止用户信息传来传去导致被劫持，但是假如token没有过期时间或者过期很长，那么显然token被劫持还是不安全的，token就失去了意义。
所以这时候大家肯定都想：那么把token过期时间设置的短一点就行啦？
是的，一般来讲accessToken的过期时间应该要短一点，但是这时候对于用户来讲就麻烦了。
因为token过期就意味着要重新登录，想象下你正浏览的好好的，突然让你掉线了并且要求你重新登录，心里肯定是想骂人的。
什么时候需要用户重新登录？
主要有三种情况：
- 1.用户长时间无操作，也可以定义未不活跃用户，就会被自动踢下，自动重定向到登录页面，超时时间可以自定义设置；
- 2.token失效，通常是双token都失效后，会要求重新登录获取新的双token；
- 3.当检测到有风险的时候，可以要求重新登录，获取token；
因此这时候就可以使用双token的设计，当两个token都过期了再要求用户重新登录，对于refreshToken，它只用来获取accessToken,不会频繁被用于请求，对于accessToken，它过期时间非常短，即使被拦截了解密也需要时间，而token本身也很快过期，因此这样的设计更加安全。
那么就这样就皆大欢喜了吗？显然不是作为前端，我们还需要实现让用户对于使用refreshToken获取accessToken的操作是无感的。
refreshToken获取token无感刷新?
总的来说一般有三种方法：
- 1.通过后端返回过期时间，前端根据当前时间与这个过期时间做判断,去调用刷新token接口
缺点：需要后端额外提供一个Token过期时间的字段；使用了本地时间判断，若本地时间被篡改，特别是本地时间比服务器时间慢时，拦截会失败。
- 2.定时任务，定时使用
refreshToken获取accessToken浪费资源,消耗性能,不建议采用。
- 3.做响应拦截器中拦截，后端判断
token返回过期后，调用刷新token接口比较好的方案，也是我在项目中使用的方案，并且axios有做响应拦截的api
这里贴一个简单的实现demo:
import axios from 'axios';
axios.interceptors.response.use(res => {
// token异常
if (res.data.code === 409) {
deleteToken();
router.push('/login')
return Promise.reject();
// 更新Token
} else if (res.data.code === 410) {
const {token} = res.data
setToken(token);// 重置token
}
return res && res.data
}
)
总结
为了用户安全因此要使用token设计，为了解决用户频繁登录，采用双token设计，同时前端也需要做一定处理。
