我應該使用OAuth 2.0中的刷新令牌發送祕密

Question

我正在努力實現OAuth 2.0服務器，並且在閱讀RFC6749規範時，我意識到有關「刷新訪問令牌」的section 6 on Page 47。解釋我們需要使用刷新令牌來獲得新的令牌。

但是，例如，除了刷新令牌之外，Google還需要用戶ID和密碼才能這樣做。

這使我很困惑，因爲一方面我們有Google每天處理大量請求的情況，而且我們有一個可能寫入規範的規範，可能在考慮範圍較小的情況下。

每個小時都用Refresh Token發送祕密是否好？

就我個人而言，我認爲不可以：因爲User ID和Secret只能用於整個OAuth 2.0流程。

基本上

1. 您使用對每個請求令牌來證明你是你是誰。
2. 刷新令牌每小時只能使用一次（並且在每次刷新時可能會更改）
3. 祕密和用戶ID儘可能少地上網。只有當選項1和2受到損害時。

我個人認爲發送帶有刷新令牌的祕密不太安全。但也許我錯過了一些東西。

如果你有另一種觀點，請分享:)

Answer 1

我可能失去了一些東西，但是谷歌需要的，什麼是還通過了OAuth2規定是從一個保密的客戶端應用程序刷新令牌時，客戶端必須認證自己。

用於機密客戶端的最常見類型的憑證是客戶端標識符以及客戶端密鑰。該信息發佈給客戶端應用程序，與最終用戶無關。

通過要求客戶端身份驗證，授權服務器可以確保請求來自特定客戶端並相應地調整其響應。例如，授權服務器可以決定某些權限範圍只能從機密客戶端請求。

圍繞減少客戶機密碼需要通過線路發送的次數的爭論是非問題。 OAuth2強制通信發生在TLS上，如果您在發送密鑰方面存在問題，那麼您也會在發送承載訪問令牌時遇到問題。

總之，雖然有時候做事情完全按規範沒有質疑的總體背景下可能導致漏洞：

...擁有經過驗證的處理與none算法簽署令牌爲有效令牌一些圖書館簽名。結果？任何人都可以用他們想要的任何有效載荷創建自己的「簽名」令牌，允許在某些系統上任意訪問帳戶。

（來源：Critical vulnerabilities in JSON Web Token libraries）

某些庫，按照規範處理的none算法，而忽視了慣用法上下文;如果開發人員通過密鑰來驗證簽名，它很可能不想將未簽名的令牌視爲有效。

但是，在刷新令牌請求上傳遞祕密不是這些情況之一，所以不用擔心。