企业应用中JWT过期后，长期未登录用户的登录状态维持方案问询

这是个非常典型的JWT落地问题，我在好几个企业级项目里都碰到过类似需求——既要保留JWT短期过期的安全特性，又要让长期不活跃的用户（比如两周没登录）在回来时能顺畅恢复状态，给你整理几个经过实践验证的方案：

1. 核心方案：Refresh Token（刷新令牌）机制 #

这是目前业界最通用的解决方案，完全契合你的需求：

• 登录流程优化：用户登录成功后，后端返回两个令牌：
  • Access Token：有效期设置得较短（比如15分钟到1小时），用来作为日常接口请求的身份凭证，符合JWT的安全设计。
  • Refresh Token：有效期设置得足够长（比如两周甚至一个月），专门用来在Access Token过期后获取新的Access Token。
• 过期处理逻辑：前端每次发起请求前先检查Access Token是否过期，如果已过期，就携带Refresh Token调用后端的/refresh-token接口，换取新的Access Token（甚至可以同时返回新的Refresh Token，实现滚动续期）。
• 安全注意事项：
  • 把Refresh Token存在HttpOnly、Secure、SameSite=Strict的Cookie中，避免前端JS读取，防范XSS攻击。
  • 后端要维护一个Refresh Token黑名单，当用户主动登出、修改密码时，将对应的Refresh Token加入黑名单，防止被恶意复用。
  • 对/refresh-token接口做限流控制，防止暴力破解。

2. 进阶优化：滑动过期（Sliding Expiration） #

如果想让活跃用户完全无感续期，可以在Refresh Token机制基础上加上滑动过期逻辑：

• 当用户使用有效的Access Token发起请求时，后端检查当前时间距离Access Token过期是否小于某个阈值（比如剩余10%的有效期），如果是，就自动返回新的Access Token（甚至新的Refresh Token）。
• 这样用户只要在Refresh Token的有效期内有过操作，就会一直自动续期，不会被强制登出；而如果用户真的超过两周没访问，Refresh Token过期后，就需要重新登录，完美保留了过期特性。

3. 简化方案：JWT+HttpOnly Cookie绑定 #

如果不想引入Refresh Token的复杂逻辑，也可以用这个简化方案：

• 登录成功后，将JWT存入HttpOnly、Secure的Cookie中，同时设置Cookie的过期时间为两周，JWT本身的过期时间也设为两周。
• 这种方式下，Cookie的有效期和JWT的过期时间同步，用户两周内访问的话Cookie自动携带JWT，过期后则需要重新登录。
• 缺点是JWT的无状态特性会打折扣（因为Cookie的有效期由后端控制），但胜在实现简单，适合中小型应用。

关键安全提醒 #

不管用哪种方案，这些细节一定要注意：

• 所有令牌的传输必须通过HTTPS，防止被中间人窃听。
• 避免将任何令牌存在localStorage或sessionStorage中，这些存储容易被XSS攻击窃取。
• 涉及敏感操作（比如修改密码、绑定手机号）时，无论令牌是否有效，都要求用户重新输入密码验证身份，防止令牌被盗用后的越权操作。

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