开启掘金成长之旅！这是我参与「掘金日新计划 · 12 月更文挑战」的第21天，点击查看活动详情
今天面试官问道一个问题，你们把从后端拿到的token存到前端缓存中，但谁都可以拿到这个token，如何保证安全性呢？
这时候我才想到，对哦。一直以来，在开发过程中，我们都是使用通过账号密码从后台获取到token，前端保存好token，后续每次请求再将token带在请求header上即可。
那么问题来了？如果别人拿到了token，岂不是可以无限期的登录你的系统。
但是后台会给token设置过期时间。
问题又来了，这个过期时间又不能设置太久，否则用户体验不好。
那？？？
经过查阅资料，在 OAuth 2.0 授权协议中, 也有两个令牌 token , 分别是 access_token 和 refresh_token
再来看下面两者的介绍
- access_token ：访问令牌, 它是一个用来访问受保护资源的凭证
- refresh_token ： 刷新令牌, 它是一个用来获取access token的凭证
以下是 OAuth 2.0 中的 token 工作流程图
详细点，如何解决以上问题呢？
颁发1小时有效期的 access_token 和8小时有效期的 refresh_token, 当 access_token 过期后（或者快要过期的时候）, 使用 refresh_token 获取一个新的 access_token, 直到 refresh_token 过期, 用户重新登录, 这样整个过程中，用户只需要登录一次, 用户体验好。
这样的话，token被泄露也没关系，因为它很快就会过期，refresh_token被泄露也没关系，因为使用 refresh_token 是需要客户端密钥 client_secret 的。
还可以进一步考虑深一点，当用户登录后，长时间不操作，这个时候如果对于安全性要求比较高的话，可以让用户重新登录，即使 refresh_token 没有过期, 因为中间有几个小时, 用户是没有操作的, 系统猜测用户已离开, 并关闭会话
最后，再做一下总结：
-
access_token时效短,refresh_token时效长, 比如access_token有效期1个小时,refresh_token有效期1天之类的 -
access_token是授权服务器一定颁发的, 而refresh_token却是可选的 -
access_token过期后, 可以使用refresh_token重新获取, 而refresh_token过期后就只能重新授权了, 也没有refresh_token了。 -
access_token和资源服务器和授权服务器交互, 而refresh_token只和授权服务器交互 -
access_token颁发后可以直接使用, 而使用refresh_token需要客户端密钥client_secret
