如何解决OAuth令牌刷新过程中出现的竞态条件问题

核心思路 #

放弃全局Mutex，改用用户粒度的并发控制逻辑，只限制同一用户同一时间仅发起一次刷新请求，不同用户的请求完全不受影响。 #

实现方案 #

方案1：用户级细粒度锁 #

• 维护一个用户唯一标识到锁实例的映射容器：比如C# 中使用ConcurrentDictionary<string, SemaphoreSlim>、Java 中使用LoadingCache<String, ReentrantLock>、Go 中使用sync.Map存储用户ID和对应锁，保证每个用户独立持有一把锁，不会阻塞其他用户的线程。
• 触发令牌刷新逻辑前，先获取对应用户的锁，仅允许当前用户的1个请求进入刷新流程，其余同用户的刷新请求进入等待状态。
• 刷新请求拿到新令牌后，先原子更新共享存储（内存缓存/Redis）中的用户令牌数据，再释放锁。后续等待的请求获取锁后，优先判断当前存储的令牌是否已经是未过期的新令牌，如果是则直接复用，不需要重复调用刷新接口。
• 给锁设置合理的超时时间，避免刷新接口异常导致锁永久占用，阻塞用户所有请求。

方案2：状态标记无锁优化 #

如果不想引入锁的复杂度，可以用状态标记的方式避免重复刷新：

• 在令牌存储结构中新增refresh_status字段，可选值为valid、refreshing。
• 当请求判断到令牌过期时，先原子性将对应用户的refresh_status从valid修改为refreshing，只有修改成功的请求有权限调用刷新接口，其余同用户的请求直接休眠短时间后重试读取令牌，直到状态变回valid。
• 刷新成功后更新令牌数据并将状态改回valid，刷新失败也需要回滚状态为valid并抛出对应异常。

方案3：适配单次有效Refresh Token规则 #

大部分OAuth服务商的Refresh Token是单次有效的，即调用一次刷新接口后旧Refresh Token直接作废，这种场景可以额外补充以下逻辑：

• 每个刷新请求执行前，先校验当前请求携带的Refresh Token是否和共享存储中存储的最新Refresh Token完全一致，不一致直接丢弃当前刷新请求，复用存储中的新令牌重试业务接口。
• 刷新接口返回新的Access Token和Refresh Token后，要原子性覆盖存储中的两个字段，避免出现部分更新的中间状态。

额外注意事项 #

• 所有令牌的读写操作必须保证原子性，不要拆分多次读取/写入，避免中间状态被其他请求读取引发异常。
• 分布式部署的Web应用不要使用进程内锁，要替换为用户粒度的分布式锁，比如用Redis的SETNX命令实现。
• 刷新失败场景可以增加重试逻辑，但是重试次数不要超过3次，避免打爆OAuth服务商接口。

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