无感刷新 Token | 接近风的地方

type

status

date

slug

summary

刷新策略

方案1：后端自动续期 Token

后端根据用户请求频率，对热点用户的过期请求自动续期token，长时间未操作的用户则不续期

优点：前端无需处理token刷新问题，根据请求频率进行续期自动适应用户行为。

缺点：可能存在滥用风险，token可能被盗用后频繁请求无限续期。

方案2：前端主动调用 RefreshToken

后端登录接口返回 accessToken 和 refreshToken，前端在适当时机主动调用 refreshToken 获取新 accessToken。

优点：精确控制刷新时机，更好的安全性。

缺点：增加前端开发复杂性，需要处理token过期情况。

如何选择：

如果应用对自动续期有一定的容忍度，并且能够有效地监控和防范滥用风险，选方案1。

如果更注重前端的控制和安全性，以及对Token刷新时机有精确要求，选方案2。

无论选择哪种方案，都需要注意在实际应用中合理设置Token的过期时间，以平衡安全性和用户体验。

关于 OAuth 2.0

OAuth 2.0（开放授权协议）是一种常用于授权的协议，它定义了多种授权流程和令牌类型，其中包括 AccessToken 和 RefreshToken。

AccessToken（访问令牌）：

AccessToken 用于访问受保护的资源，代表了授权给第三方应用的权限。与传统的用户名密码认证相比，AccessToken 实现了一种轻量级的身份验证机制，避免了直接暴露用户的用户名和密码。AccessToken 的有效期通常比较短，以增加安全性。即使AccessToken泄漏，攻击者也只能在有效期内滥用，有效期结束后需要重新获取。

RefreshToken（刷新令牌）：

RefreshToken 具有相对较长的有效期，通常比 AccessToken 长。它用于获取新的 AccessToken，即使原始AccessToken 过期，RefreshToken 仍然有效，从而实现了无感刷新令牌的机制。RefreshToken 的存在减轻了用户频繁进行登录操作的需求，通过 RefreshToken 刷新 AccessToken，用户在使用过程中无需频繁跳出重新登录。

基于OAuth 2.0标准，我们选择采用方案2实现token的无感刷新，下面来看如何实现：

前端实现

后端从 login 接口返回

刷新时机

前端用定时器定时调用刷新接口，易于实现但浪费资源，不推荐

前端在token即将过期时刷新，需要与expires做对比，依赖于客户端本地时间，不推荐

前端根据后端响应状态（如401未授权）按需刷新，推荐

处理拦截器

请求拦截器：

缓存刷新过程中拦截到的所有请求

响应拦截器：

对已401状态的响应缓存本次请求，同时执行token刷新

useRefreshToken：

自定义 hook 实现刷新方法

后端实现

前端把refreshToken传给后端，后端拿到refreshToken去redis中检查当前refreshToken是否失效，如果失效就报错，没失效就颁发一个新的token给前端。这里注意一下，不要生成新的refreshToken返回给前端，不然如果别人拿到一次refreshToken后，可以一直刷新拿新token了。