Spring Boot2整合Angular实现JWT时refresh_token工作机制相关疑问

现有设计的合理部分 #

• 有效期配置符合行业通用规范：15分钟有效期的access_token降低了令牌泄露后的风险窗口，7天有效期的refresh_token避免用户频繁登录，平衡了安全性和使用体验。
• 双密钥设计完全正确：access_token和refresh_token使用不同的签名密钥，可从根本上避免refresh token被滥用直接访问业务资源的问题。注意后端要做好校验逻辑隔离：普通业务接口仅用access密钥校验请求头中的Authorization: Bearer ACCESS_TOKEN，/refresh_token接口仅用refresh密钥校验刷新凭证，两类校验逻辑完全独立。

需要补充优化的逻辑 #

现有核心思路没有原则性错误，只需补充以下安全和边界处理规则即可落地：

• 增加refresh token轮换与作废机制：每次刷新返回新的access_token和refresh_token的同时，必须将旧的refresh_token立即标记作废，禁止重复使用，避免令牌泄露后被长期滥用。如果存在多端并发刷新的场景，可以给旧refresh_token设置10秒以内的宽限期，宽限期结束后立即禁用。
• 后端存储refresh token全量信息：不要仅依赖JWT本身的签名做校验，需要将所有有效refresh_token和对应用户ID、过期时间存储在Redis或数据库中，用户登出、账号异常时可以直接删除对应令牌实现强制下线，避免被盗令牌持续生效。
• 优化前端刷新触发逻辑：Angular端不要依赖本地时间判断access_token是否过期，建议通过HTTP拦截器监听业务接口返回的401状态码，自动触发刷新流程。如果/refresh_token接口也返回401，说明refresh_token已过期或作废，直接跳转登录页让用户重新认证。
• 强化传输和存储安全：所有接口必须走HTTPS避免令牌传输被截获。前端侧access_token建议存储在内存中，refresh_token要存储在开启HttpOnly、Secure、SameSite属性的Cookie中，不要存储在localStorage/sessionStorage，降低XSS攻击窃取令牌的风险。
• 调整refresh请求的传参方式：不建议用Authorization头携带refresh_token，如果你采用HttpOnly Cookie存储refresh_token，请求时浏览器会自动携带，无需前端手动处理，进一步降低泄露风险。如果要自定义传参，建议使用独立的请求头如X-Refresh-Token，避免和access_token的传参逻辑混淆。

整体方案的核心设计方向是正确的，补充上述规则后即可满足生产环境的安全要求。

内容的提问来源于stack exchange，提问作者korallo