OAuth2移动端刷新令牌请求期间应用被杀死的问题处理咨询

方案1：后端给Refresh Token加延迟失效标记 #

• 后端处理刷新请求时，先把旧Refresh Token标记为「待失效」，不直接删除有效性。
• 设定一个比用户可能断连的时间更长的超时窗口（比如30分钟，覆盖你提到的20分钟场景），超时后再彻底作废旧Token。
• 这段时间内如果客户端用旧Token再次请求，后端查到「待失效」状态，就重新签发新的Access Token和Refresh Token，同时更新标记。这样用户20分钟后回来的请求能直接成功，不用强制登出。

方案2：客户端本地记录刷新请求状态 #

• 发起刷新请求前，客户端把当前Refresh Token和「正在刷新」的状态持久化存起来（比如本地数据库、Keychain这类安全存储）。
• 用户重新打开应用时，先检查有没有「正在刷新」的状态：
  • 有的话，直接调用后端新增的查询接口，用旧Refresh Token查是否已经签发过新令牌；
  • 后端返回已签发的话，客户端拿新令牌更新本地存储，清除「正在刷新」状态；
  • 没签发的话，再发起正常的刷新请求。

方案3：调整Refresh Token轮转规则 #

• 改成「两次有效」的轮转逻辑：第一次用旧Token换了新Token后，旧Token不会立即失效，直到用新Token完成第二次刷新，旧Token才彻底作废。
• 这种情况下，用户杀应用后回来用旧Token请求，后端依然会返回新令牌，同时把旧Token标记失效，既解决场景问题，也能避免旧Token被多次滥用。

实用建议 #

• 可以把方案1和方案2组合使用，客户端记录状态+后端延迟失效，可靠性更高。
• 延迟失效窗口别设太长，比如最长不超过1小时，防止旧Token被盗用的风险；客户端的状态要加密存储，避免本地数据被篡改。

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