处理 OAuth2 刷新令牌竞争条件

Question

我们正在为我们的应用程序实现“BFF”（前端后端）模式，这是 draft-ietf-oauth-browser-based-apps 的建议。

我们遇到的一个复杂问题是处理 OAuth2 刷新。两个请求几乎并行运行对我们来说并不罕见。如果这种情况下的访问令牌已过期，它们可能都会尝试发起刷新，这意味着第一个请求获胜。

有几种方法可以解决这个问题：

• 乐观地在令牌过期之前刷新令牌。问题是我们需要为每个活动会话维护大量状态。
• 创建锁定系统。假设有多个后端实例时，这并不容易。
• 放宽刷新令牌的单次使用要求，因此多个并行请求都可以成功。这感觉有点危险。

我很好奇是否有任何已知的最佳实践

Answer 1

我总是处理这个客户端，通常会布置一棵同时调用 API 的视图树。并发刷新最容易处理客户端。

BFF 可以提供这样的端点来启用令牌刷新，尽管 JavaScript 应用程序决定何时调用它：

• 发布/刷新

这会导致调用 API 的代码表现如下

let response = await callApi(options);
if (response.status === 401)
    await synchronizedRefresh():
    response = await callApi(options);
}

synchronizedRefresh

方法通过对 Promise 集合进行排队相当容易编写。但实际上只调用第一个视图的刷新端点。刷新完成后，您可以以相同的结果解决所有承诺。