门卫刷新令牌和并发

Question

在当前门卫的实现中，当刷新access_token时，门卫也会发送一个新的refresh_token。这是一个有效的实现，但是当来自客户端的并发apis调用（ios，android ）调用同时刷新访问令牌。这意味着至少有一个线程会以不能刷新的过期令牌结束。

任何人都有这种竞争条件的解决方案？

Answer 1

我们已经解决了这个问题（不是门卫）有几种不同的方法。

请求队列：

在我们的移动应用程序，我们已经实现了一个请求队列，并只需提出要求之前，我们是否需要刷新令牌，然后，我们暂停了队列，刷新令牌，然后再次取消暂停。在这种情况下不需要更改服务器

这有折衷（您需要同步您的请求线程等），但是在停止刷新争用而不需要修改服务器时非常可靠。

刷新抖动和智威汤逊：

由于我们使用的智威汤逊（其中access_token到期写入令牌，并在服务器端没有被撤销），您可以添加的“抖动秒”的随机数每次检查时刷新到期。这减少了两个请求同时尝试刷新的可能性。我在一个AngularJS应用程序中使用这个应用程序，它会让所有与打开的多个标签混淆。随机选择一个标签会在其他标签之间刷新，而其他标签可以继续使用其现有的access_token，直到新标签返回并更新。

如果您可以设法使您的access_tokens在使用其相应的刷新标记时保持有效，这将允许“其他”请求继续使用其“旧”标记，直到下一个标记时间。

这不是完全万无一失，但降低了我们对此感到满意的可能性。

到期缓冲区来标记：

最后的方法是被执行刷新时，实际上并不到期令牌，几秒钟后，所以任何“并行”的线程只是得到返回的新令牌。当我从头开始编写服务器组件时，这很容易，但门卫可能不那么容易。我认为你会从另外两种方法中获得更多的milage。