從刷新令牌獲取訪問令牌失敗並出現 invalid_grant 錯誤，並且錯誤請求或令牌已過期或作為錯誤描述被撤銷

Question

使用Java OAuth2 客戶端庫： scribe 1.2.0 ( https://github.com/scribejava/scribejava )

我能夠從授權代碼中獲取刷新令牌（即；通過使用 client_id、client_secret、code、scope、 grant_type (authorization_code) 、redirect_uri 參數對https://accounts.google.com/o/oauth2/token進行 POST 調用）。 而且我已經在數據庫中保留了刷新令牌。 而且我們支持驅動器和日歷范圍 => 所以，我確實為每個用戶存儲了兩個刷新令牌（電子郵件）

然后客戶端將調用 API 以獲取訪問令牌（然后我正在使用 refresh_token、 grant_type (refresh_token) 、client_id 和 client_secret 對https://accounts.google.com/o/oauth2/token進行 POST 調用） 並且通話成功。 IE; 快樂的正常路徑有效。

但最終從刷新令牌獲取新訪問令牌失敗並出現invalid_grant錯誤代碼（錯誤請求或令牌已過期或被撤銷為錯誤）（如 2 天或 3 天等）

請注意，刷新令牌不會被用戶或代碼顯式撤銷或無效。 密碼未更改。 代碼沒有改變。 客戶 ID 和機密沒有改變。 我有點迷路了。

問題

1. 由於刷新令牌應該是一個持久令牌，為什么我的應用程序無法從刷新令牌中獲取新的訪問令牌？ 它只是在2 到 3天內就失敗了——而且它在舞台和生產環境中經常發生。

2. 是否基於 scope（驅動器和日歷）存儲兩個刷新令牌 - 每個用戶（電子郵件）問題（即；一旦發出第二個刷新令牌，前一個刷新令牌就會過期）？ [不應該是這樣- 我知道每個用戶和客戶端，每個用戶對所有客戶端都有限制。 但是，2 太低，無法達到該限制。]

答案終於能夠解決它，請參閱下面的評論答案 - 它與具有相同 email 的兩個刷新令牌用於不同的范圍，並使其中一個無效有關。

從刷新令牌獲取訪問令牌 - PostMan

從授權碼獲取刷新令牌 - PostMan

相關問題： 谷歌令牌刷新返回“令牌已過期或撤銷”。 幾天以來，刷新令牌已自動過期

Answer 1

更改密碼

您的刷新令牌可能會過期有多種原因。 我們可以鎖定的第一個原因是用戶更改密碼，如果您使用的是 gmail scope 並且用戶更改密碼，這將導致所有未完成的刷新令牌過期。

用戶撤銷訪問

如果用戶直接通過他們的 Google 帳戶撤銷您的訪問權限，這也將撤銷您的刷新令牌。

申請狀態。

現在你的應用還在谷歌雲控制台上測試嗎？ 您是否已將其移至已發布，是否已通過驗證過程？ 如果不是這樣，那么您的刷新令牌可能會在大約兩周后過期，盡管時間框架可能已經改變，因為這似乎是谷歌過去幾個月一直在努力的事情，並且沒有官方消息。

刷新訪問令牌提供刷新令牌。

實際上可能是這種情況的另一個原因是，當您刷新訪問令牌時，它是否會返回一個新的刷新令牌。 有時我會這樣做。 始終檢查這是否與您之前使用的刷新令牌相同，如果注意則它是一個新令牌，您應該存儲新令牌。 有關原因的更多信息，請參閱下一點。

未完成的刷新令牌的最大數量。

當用戶使用離線訪問授權您的應用程序時，您將獲得一個刷新令牌，如果用戶再次授權您的應用程序，您將獲得另一個刷新令牌。 您最多可以繼續執行此操作 50 次，所有 50 個刷新令牌都將繼續工作。 一旦您的 go 超過 50 的幻數，那么創建的第一個將過期。 這就是為什么確保始終在數據庫中存儲用戶的最新刷新令牌很重要的原因。

Answer 2

基本上，如果您的應用為同一用戶（Gmail）有多個不同范圍的刷新令牌，使其中一個無效將使所有令牌無效。

事實證明這是問題所在，因為我們根據范圍（例如驅動器、日歷、聯系人等）維護不同的刷新令牌