SpringBoot中基于JWT的双token（access_token+refresh_token）授权和续期方案

微服务架构中，JWT认证方案中，用户登录成功后，后端会生成一个JWT格式的access_token并发送给前端。前端接收后，会将此access_token安全地存储在浏览器的LocalStorage中，以便在后续请求中作为身份认证的依据。

每次API请求时，前端都会将access_token附加在请求头中发送给后端，后端则通过过滤器验证其有效性和未过期状态。然而，鉴于access_token通常包含用户敏感信息且为了安全考虑设置较短的过期时间，这可能导致用户在长时间使用应用时频繁遇到登录过期的问题，特别是在进行长时间操作如填写复杂表单时，如在线考试。

引入refresh_token实现自动续期

为了解决上述问题，通常引入refresh_token机制。refresh_token是一个长期有效的令牌，与access_token一同在用户初次认证时由后端生成并返回给前端。refresh_token应当被安全地存储在客户端，其重要性等同于用户密码。

工作原理：

1. 初次认证：用户登录成功，后端生成access_token和refresh_token，access_token用于后续的API访问，而refresh_token则用于在access_token过期时请求新的access_token。
2. API访问：前端携带access_token访问后端资源，后端验证其有效性。若access_token未过期，则正常处理请求；若已过期，则返回一个特定的错误码，提示前端使用refresh_token刷新access_token。
3. 自动续期：前端捕捉到access_token过期的错误码后，在用户无感知的情况下，使用refresh_token向后端请求新的access_token。成功获取后，前端更新本地的access_token，并继续处理之前的请求或允许用户继续操作。
4. 安全性与策略：
   • refresh_token应当设置较长的过期时间，但并非永久有效，以防止长时间未使用账号的风险。
   • 当用户登出或检测到潜在的安全风险时，注销旧的token，使 access_token 和 refresh_token 失效，同时清空客户端的 access_token 和 refresh_toke。
   • refresh_token的使用应受频率限制，防止滥用。

当然为了更安全，refresh_token其实也可以存储在后端，比如将其存储在redis的中kv中access_token:refresh_token，方式很多，但基本思想一致。当然如果存储在redis中,还不如这种方式了:

关注公众号[码到三十五]获取更多技术干货 !