我是否需要使用OAuth 2訪問令牌來保護我的API端點（資源）？

Question

OAuth2談話中涉及多方參與。從文章here

想想看，我有一個爲restaurants有數據，以及具有與它的API的應用程序考慮 如下圖。我們稱之爲restaurant的API。讓我們分配本例中

User - our chefs, who have some recipes in restaurant 

Application - Web client written in HTML5, JS, CSS that our Users use to interact with APIs 

OAuth Endpoint - Google (who acts as Authorization Server) 

API - My application API keeping all data for chefs 

的背景下一些作用，每一方

爲Implicit工作流（按照上面的鏈接圖）規定的Application得到access token，然後Application（瀏覽器）調用API（我申請廚師食譜）並獲取數據。

問題

• 我不應該secure我的應用程序的端點或者說只相信accesssTokens？是的，信託建立在Application和OAuth Endpoint（Google）之間，但是沒有trust開發API和Application確認accessToken與OAuth Endpoint（Google）的有效性？

• 如果我要保護我的應用程序API終點，我將有一個/login終點爲我APIs在我的應用程序接受accessTokens，驗證，並創建一個基於JWT頭，爲客戶作進一步的溝通與保護資源，如/recipes使用。

期待您的想法在這裏。
在此先感謝

Answer 1

TL; DR-不要盲目信任訪問令牌。要求Google公開與其關聯的用戶/電子郵件以及生成時使用的客戶端ID。您仍然可以提供一個/login端點，以實現可擴展性。

讓我們處理核心安全第一

OAuth是一個代表團的協議，而不是一個身份驗證協議。從the OAuth website引用：

OAuth 2.0規範定義了委託協議[...] OAuth用於各種應用程序，包括提供用戶身份驗證的機制。 [...]我們再說一遍，要清楚：

OAuth 2.0不是一個身份驗證協議。

因爲它不是一個身份驗證協議，您的應用程序/ API永遠不會知道用戶是誰。它只是得到一個令牌。在這種情況下的委派意味着，OAuth通過讓用戶對App B進行身份驗證，然後將該令牌傳遞迴App A，讓App A請求訪問屬於某個用戶的App B中的資源。在您的示例中，它可以爲您的網絡應用提供用戶（廚師）擁有的Google資源（電子郵件，照片等 - 取決於所需的scope）。

請注意，這不是你在這裏做的，因爲你正在訪問由管理的資源，而不是你的應用，而不是Google。特別是，正如您正確識別的那樣，訪問令牌對您的API沒有任何意義。我可以給它一個隨機字符串。

你也許會使用以下方案：

• 在你的問題中所述落實隱式。
• 讓API服務器使用Google驗證訪問令牌，並要求Google提供與令牌關聯的名稱或電子郵件。這將是實際登錄Google的用戶的身份，然後您可以決定是否授予該用戶權限。

這種方法的問題在於許多應用程序在Google上使用OAuth，所以很多應用程序都會讓Google訪問令牌不屬於您的應用程序。你怎麼能區分這個區別？

當您向訪問令牌提供時，您可以要求Google向您提供在生成此令牌時提供的客戶端ID（請參閱您的圖表指示客戶端ID是如何發送的？） 。由於該客戶端ID唯一標識了您的應用，因此您的API可以告訴它只有來自您的應用的令牌。請注意，OAuth流程的這個關鍵部分在移動應用程序中有很大不同，這就是隱式流程不應用於移動應用程序的原因（但對於Web應用程序來說它沒問題）。

請注意，您的客戶端ID應該被視爲常識（例如，它可以在執行此流程的計算機上的.js文件中找到），但它不能被欺騙，因爲作爲OAuth流程的一部分，用戶的瀏覽器將被重定向到Google預先配置並且屬於您的應用的網址。因此，即使惡意應用程序使用您的客戶端ID，Google仍會將令牌發送給您的應用程序。上述

其他實用性

需要你在每個API調用發給谷歌的電話，或至少緩存有效的訪問令牌（這意味着你保持狀態，這是實現可伸縮性的無賴）。如果您想避免這種情況，您可以創建一個生成JWT的端點/login。請注意，您仍然需要在登錄時驗證訪問令牌。