門衛刷新令牌和併發

Question

在當前門衛的實現中，當刷新access_token時，門衛也會發送一個新的refresh_token。這是一個有效的實現，但是當來自客戶端的併發apis調用（ios，android ）調用同時刷新訪問令牌。這意味着至少有一個線程會以不能刷新的過期令牌結束。

任何人都有這種競爭條件的解決方案？

Answer 1

我們已經解決了這個問題（不是門衛）有幾種不同的方法。

請求隊列：

在我們的移動應用程序，我們已經實現了一個請求隊列，並只需提出要求之前，我們是否需要刷新令牌，然後，我們暫停了隊列，刷新令牌，然後再次取消暫停。在這種情況下不需要更改服務器

這有折衷（您需要同步您的請求線程等），但是在停止刷新爭用而不需要修改服務器時非常可靠。

刷新抖動和智威湯遜：

由於我們使用的智威湯遜（其中access_token到期寫入令牌，並在服務器端沒有被撤銷），您可以添加的「抖動秒」的隨機數每次檢查時刷新到期。這減少了兩個請求同時嘗試刷新的可能性。我在一個AngularJS應用程序中使用這個應用程序，它會讓所有與打開的多個標籤混淆。隨機選擇一個標籤會在其他標籤之間刷新，而其他標籤可以繼續使用其現有的access_token，直到新標籤返回並更新。

如果您可以設法使您的access_tokens在使用其相應的刷新標記時保持有效，這將允許「其他」請求繼續使用其「舊」標記，直到下一個標記時間。

這不是完全萬無一失，但降低了我們對此感到滿意的可能性。

到期緩衝區來標記：

最後的方法是被執行刷新時，實際上並不到期令牌，幾秒鐘後，所以任何「並行」的線程只是得到返回的新令牌。當我從頭開始編寫服務器組件時，這很容易，但門衛可能不那麼容易。我認爲你會從另外兩種方法中獲得更多的milage。