微服务架构中，JWT认证方案中，用户登录成功后，后端会生成一个JWT格式的access_token并发送给前端。前端接收后，会将此access_token安全地存储在浏览器的LocalStorage中，以便在后续请求中作为身份认证的依据。
每次API请求时，前端都会将access_token附加在请求头中发送给后端，后端则通过过滤器验证其有效性和未过期状态。然而，鉴于access_token通常包含用户敏感信息且为了安全考虑设置较短的过期时间，这可能导致用户在长时间使用应用时频繁遇到登录过期的问题，特别是在进行长时间操作如填写复杂表单时，如在线考试。
jwt单token方案参考: SpringBoot中基于JWT的单token授权和续期方案
引入refresh_token实现自动续期
为了解决上述问题，通常引入refresh_token机制。refresh_token是一个长期有效的令牌，与access_token一同在用户初次认证时由后端生成并返回给前端。refresh_token应当被安全地存储在客户端，其重要性等同于用户密码。
工作原理：
初次认证：用户登录成功，后端生成
access_token和refresh_token，access_token用于后续的API访问，而refresh_token则用于在access_token过期时请求新的access_token。API访问：前端携带
access_token访问后端资源，后端验证其有效性。若access_token未过期，则正常处理请求；若已过期，则返回一个特定的错误码，提示前端使用refresh_token刷新access_token。自动续期：前端捕捉到
access_token过期的错误码后，在用户无感知的情况下，使用refresh_token向后端请求新的access_token。成功获取后，前端更新本地的access_token，并继续处理之前的请求或允许用户继续操作。安全性与策略：
refresh_token应当设置较长的过期时间，但并非永久有效，以防止长时间未使用账号的风险。当用户登出或检测到潜在的安全风险时，注销旧的token，使 access_token 和 refresh_token 失效，同时清空客户端的 access_token 和 refresh_toke。 refresh_token的使用应受频率限制，防止滥用。
当然为了更安全，refresh_token其实也可以存储在后端，比如将其存储在redis的中kv中access_token:refresh_token，方式很多，但基本思想一致。当然如果又引入redis，还不如非jwt方案: SpringBoot中Token登录授权、续期和主动终止的方案(Redis+Token)
点赞+转发+在看 就是最大的支持!
