如何有效使用API​​密鑰和令牌方案來保護REST API？

Question

我知道這個問題已經被問了很多次，形式和形式各不相同，但我對於一些事情還是很不清楚。令人困惑的是，圍繞Web的這個主題的資源如何引用沒有明確上下文的「用戶」。 API密鑰是爲用戶頒發的，訪問令牌也是如此，但我不認爲API密鑰用戶與訪問令牌用戶相同。

• 您是否需要針對最終用戶客戶端的不同實例擁有不同的API密鑰？例如，如果我爲第三方API構建移動應用程序，每個實例是否保留其自己的API密鑰？我不認爲他們這樣做，但我怎麼綁定API密鑰，並將令牌一起訪問，以表示某個請求來自某個已知用戶授權的應用程序的特定實例？如果我是auth提供者，我是否必須跟蹤每一個？
• API密鑰和訪問令牌通常由一對公共密鑰和共享密鑰表示。作爲服務提供者（服務器端），我使用哪一個來驗證我收到的消息，API密鑰或訪問令牌？如果我理解正確，這個想法是每個請求應該帶有從API密鑰的祕密部分派生的簽名，以便服務器可以檢查它是否來自可信客戶端。現在我有什麼使用訪問令牌的祕密？我知道訪問令牌用於驗證系統用戶是否已授權應用程序代表他們執行操作，但是訪問令牌的哪些部分會對訪問令牌密碼有用？
• 是從一個（安全）隨機數生成的一個散列，和一個時間戳salt是一個很好的API密鑰生成策略？
• 是否有（最好是開源的，基於Java的）框架能夠完成其中的大部分工作？

Answer 1

讓我試着回答儘可能多的問題。

Apikey VS訪問令牌的使用

• 首先，apikeys是不是每個用戶使用。每個 應用程序（開發人員）分配Apikeys。一個服務的開發者註冊他們的應用程序，並獲得一對密鑰 。
• 另一方面，在使用的上下文中爲每個 最終用戶頒發訪問令牌（例外情況是Client Credential 授予）。
• 服務提供商可以從使用中的 apikey中識別應用程序。
• 服務提供商可以使用 訪問令牌屬性來識別最終用戶。
• 您應該有任何最終用戶API，即具有關聯的最終用戶資源（數據或上下文）的API，受3段Oauth保護。所以訪問令牌應該是訪問這些資源所必需的。
• 開發人員專用資源可以通過apikey或雙腿Oauth進行保護。這裏我指的是Oauth2標準。
• 當沒有HTTPS支持時，首選Oauth1。這樣共享密鑰不會通過不受保護的通道發送。相反，它用於生成簽名。我強烈建議通過HTTP使用Oauth2，並避免使用Oauth1。你和你的API消費者會發現Oauth2更容易實現和使用。除非您有特定的理由使用Oauth v1

作爲服務提供商，您可以使用提供Oauth 1和2的Apigee Edge平臺。它不是開源的。但是，您可以免費使用它，直到您需要一些高TPS或更高的SLA。