在门卫的当前实现中，当刷新access_token时，门卫也发送一个新的refresh_token。这是一个有效的实现，但是当我的客户端（ios，android）调用刷新的并发apis调用时它会成为问题。同时访问令牌。这意味着至少有一个线程以过期的令牌结束，无法刷新。
任何人都有这种竞争条件的解决方案吗？
答案 0 :(得分：1)
我们之前（不是使用门卫）以几种不同的方式解决了这个问题。
请求队列：
在我们的移动应用程序中，我们已经实现了请求队列，在请求发出之前，我们检查是否需要刷新令牌，然后我们暂停队列，刷新令牌，然后再次取消暂停。在这种情况下，无需更改服务器
这需要权衡（您需要同步您的请求线程等），但在停止刷新争用而不需要修改服务器方面非常可靠。
刷新抖动和JWT ：
由于我们使用JWT（access_token到期被写入令牌并且未在服务器端撤销），您可以添加随机数＆＃34;抖动秒＆＃34;每次检查时刷新到期。这降低了两个请求同时尝试刷新的可能性。我在一个AngularJS应用程序中使用了这个，这个应用程序可能会打开几个标签。在其余部分之前，有一个选项卡会随机刷新，其余部分可以继续使用现有的access_token，直到新的选项卡被返回并更新。
如果你可以设法让你的access_tokens在使用相应的刷新令牌时保持有效，那么这可能也可以在没有JWT的情况下工作，这将允许其他人使用#t;要求继续使用他们的旧版＆＃39;令牌直到下一次。
它并非完全万无一失，但降低了我们对此感到满意的可能性。
令牌的到期缓冲区：
最后一种方式是执行刷新时，几秒钟之后实际上不会使令牌过期，因此任何＆＃39;并发＆＃39;线程只是返回新的令牌。当我从头开始编写服务器组件时，这很容易，但对于门卫来说可能不那么容易。我认为你可以从其他两种方法中获得更多的变化。