Google OAuth令牌驗證執行的方式和原因？

Question

在訪問令牌，刷新令牌，範圍，受衆羣體和客戶端ID之間，當Google OAuth文檔告訴我validate all tokens以防止混淆代理問題時，我感到困惑。 The Wikipedia article linked to只描述高級別的一般問題，並非特定於OAuth甚至網絡身份驗證。如果我理解正確，令牌驗證甚至不是OAuth2的一部分，但實際上取決於具體的實現。所以這裏是我的問題：

Google OAuth令牌驗證如何以及爲什麼執行？

在這種情況下，一個混淆副代表問題的具體例子將受到特別讚賞。另外請注意，我會在完全客戶端應用程序的環境中提出這個問題，如果這有所幫助的話。

Answer 1

谷歌是專門指訪問令牌。

在OAuth 2.0的環境中，當用於身份驗證時，混淆的代理問題適用於Implicit Grant protocol flow。 Google稱之爲「客戶端應用程序的OAuth 2.0」基於隱式授權協議流程。

由於隱式流暴露訪問令牌通過URI片段最終用戶，它引入了訪問令牌可能被篡改的方法可行。一個合法的應用程序（一個OAuth客戶端）可以通過接受發給不同（惡意）應用程序的訪問令牌而成爲令人迷惑的代理，從而使攻擊者能夠訪問受害者的帳戶。

在驗證訪問令牌中的關鍵步驟是，應用程序驗證的訪問令牌不最初發布到不同的應用程序。 Google calls attention to this when they say：

注：驗證一個道理，關鍵是要確保完全匹配的API控制檯註冊您的CLIENT_ID響應觀衆的現場。這是對混淆的代理問題的緩解，並且執行這一步驟至關重要。

作爲一個簡單的例子，假設有兩個應用程序：（1）FileStore，一個合法的文件存儲應用程序，和（2）EvilApp。這兩款應用都使用Google的身份驗證程序處理客戶端應用程序。 Alice是一個天真的最終用戶，她的Google用戶ID是XYZ。

1. 愛麗絲簽署到FileStore的使用谷歌。
2. 驗證過程結束後，FileStore爲Alice創建一個帳戶並將其與Google用戶ID XYZ關聯。
3. Alice將一些文件上傳到她的FileStore帳戶。到目前爲止，一切都很好。
4. 後來，Alice登錄到EvilApp，它提供了一些看起來很有趣的遊戲。
5. 因此，EvilApp獲得與Google用戶ID XYZ關聯的訪問令牌。
6. EvilApp的所有者現在可以爲FileStore構建重定向URI，插入爲Alice的Google帳戶發佈的訪問令牌。
7. 攻擊者連接到FileStore，FileStore將獲取訪問令牌並與Google進行覈對以查看該用戶的用途。谷歌會說它是用戶XYZ。
8. FileStore會讓攻擊者訪問Alice的文件，因爲攻擊者擁有Google用戶XYZ的訪問令牌。

FileStore的錯誤是沒有向Google驗證它給出的訪問令牌是否真正發佈到FileStore;令牌確實發給了EvilApp。

其他人比我更優雅的描述是：

• http://www.thread-safe.com/2012/02/more-on-oauth-implicit-flow-application.html
• http://www.thread-safe.com/2012/01/problem-with-oauth-for-authentication.html
• http://tools.ietf.org/html/rfc6749#section-10.16

我希望這解釋了爲什麼用客戶端訪問令牌驗證一部分側邊的應用程序，以及它如何與混淆的副手問題聯繫起來。

Answer 2

您是如何使用OAuth2的？你是否獲得授權碼並交換刷新令牌？或者你是否通過你的前端直接獲得訪問令牌？

如果您接收到授權碼，您就完成了，因爲Google在後臺執行的client_secret檢查可以確保爲您的應用程序頒發所有令牌，以交換授權碼。

如果您通過前端接收到access_token + id_token，那麼您應該使用推薦的庫驗證id_token簽名，然後驗證id_token中的'aud'字段是否與您爲您的應用程序註冊過的字段匹配。對於完整的安全，也交叉驗證與id_token所述的access_token（該id_token包括的access_token所提交「at_hash」的截短散列），如記載：https://developers.google.com/accounts/docs/OAuth2Login