使用指定的客戶端密鑰設計API

Question

我正在設計一個JSON Web API，並希望通過唯一ID來區分客戶端，以便監控使用情況並阻止惡意/行為不端的客戶端。 API不是封裝在JavaScript庫中，也不是Web應用程序獨有的，任何客戶端類型都可以使用它（桌面，電話等）。

問題是，Web應用程序（官方網站）也是API本身的客戶端 ，因此必須公開其API密鑰。 因此，某些用戶可以從頁面上的JavaScript中提取密鑰並使用它，而不是生成自己的密鑰。

是否有可能以某種更好/更聰明的設計選擇來某種方式緩解這個問題，或者我是否必須忍受這樣一個事實：任何惡意使用API​​的人都可以利用這個？

我可以100％控制前端應用程序（EmberJS）和后端服務器（Go），因此可以建議任何更改。

• 我正在使用每個會話/ ip的速率限制為該情況添加額外的保護層
• twitter.com頁面曾經也是自己API的客戶端。 他們是如何解決的？

注意：問題不在於身份驗證或安全性本身，而是如何要求第三方用戶另外使用API​​密鑰（！）進行身份驗證！

Answer 1

您應該區分Web和非Web客戶端。 Web的訪問密鑰不能在非Web中使用，反之亦然。 對於Web客戶端，您可以進行引用檢查等。您還可以為應用程序動態創建訪問密鑰，並每天（或每個會話）自動更改它們。 您還可以僅為您的應用添加一些特殊驗證，例如由混淆的JS計算的一些額外密鑰。

沒有什么能阻止惡意用戶模仿瀏覽器，執行JS，操縱它，然后做壞事 - 但是你可以讓它煩人，以至於他們認為不值得他們付出努力。 顯然需要在服務器端檢查權限等非常重要的事情，因此濫用您的API不應該是一個大問題。 您必須通過網站的API密鑰處理API濫用行為，與常規網絡應用濫用行為相同 - IP阻止等。

您仍然需要保密非Web客戶端的API密鑰。 這只能通過混淆不可靠地完成，您可以將其留在客戶端開發人員手中。 如果他們的密鑰被泄露和濫用，你撤銷它，他們將有動力解決它。

看看OAuth 2.0 ，它們會阻止許多可能對您有用的功能。 即使你不想使用它，你也可以從中獲得靈感。 OpenStreetMap使用OAuth（不確定是1還是2）作為基於flash的編輯器; 只要登錄用戶從同一來源調用，OAuth權限授予就會自動完成。 對於第三方應用，用戶需要手動執行此操作。 您可能想要檢查出來。

Answer 2

只使用一個API密鑰，您將無法保證API的安全。 您描述的API密鑰基本上是一個公鑰，您需要某種類型的私鑰來進行安全識別/身份驗證，並提供一種機制來提供它。

你問過Twitter是如何解決這個問題的。 他們使用Oath 1.0a。 以下是關於它如何與Twitter Developer FAQ中的API密鑰相關聯的簡要說明。

大多數與API的集成將要求您通過API密鑰向Twitter標識您的應用程序。 在Twitter平台上，術語“API密鑰”通常指的是所謂的OAuth使用者密鑰。 此字符串在向API發出請求時標識您的應用程序。 在OAuth 1.0a中，您的“API密鑰”可能指的是此消費者密鑰和“消費者密鑰”的組合，這是一個用於安全地“簽署”您對Twitter的請求的字符串。 除了應用程序上下文之外，對Twitter的大多數請求都需要用戶上下文。 通過使用稱為“訪問令牌”的另一種令牌/密鑰來呈現用戶上下文。 有關更多信息，請參閱獲取訪問令牌。

您可以在Apigee.com上找到很多有關設計API的優秀資源。 他們建議使用OAuth 2.0進行身份驗證/授權。

以下是如何使用HMAC身份驗證來保護Web API的說明 。

當我不得不使用僅使用API​​密鑰的API時，我已經為我的Web應用程序使用了一種解決方法。 我不直接從Web應用程序的客戶端部分訪問API（即Web瀏覽器中的JavaScript）。 相反，我訪問API服務器端並將加密的API密鑰存儲在安全配置文件中。 我提供了原始API的Facade，並使用我自己的安全方法來保護依賴於應用程序類型的Facade API。

Answer 3

一般API工作流程：

1. 客戶端發送請求
2. 請求已通過身份驗證和授權
3. 數據被發回

網站 - 登錄

1. 用戶登錄提供用戶名和密碼
2. 創建一個秘密並存儲到一個coockie中

網站 - API訪問

1. 客戶端發送請求
2. 請求根據coockie的秘密進行身份驗證和授權（隨請求發送coockies）
3. 數據被發回

非WEB客戶端 - 獲取API KEY（長隨機字母數字字符串）

1. 選項1 - 用戶在網站上注冊客戶端，獲取API KEY並將其存儲到客戶端
2. 選項2 - 用戶輸入用戶名和密碼到客戶端，客戶端使用usenamer和密碼請求API KEY，返回密鑰並存儲到客戶端。 用戶名和密碼不存儲在客戶端上。

非WEB客戶端 - API通信

1. 客戶端使用API​​ KEY發送請求
2. 請求已根據API-KEY進行身份驗證和授權
3. 數據被發回

當使用選項2生成密鑰時，您可以獲得一些額外的數據，因為它來自客戶端（操作系統，瀏覽器）。 在這種情況下，當檢查API-KEY時，如果他更改了操作系統或瀏覽器，則可以強制用戶生成新的API

關鍵是您的API以兩種方式驗證請求。 使用coockie的秘密或API KEY。 因此，無需在網站上公開API-KEY。

請注意，對於使用API​​-KEY的客戶端，不涉及任何會話。 每個請求僅通過API-KEY進行身份驗證。 所以這些客戶端被認為是非WEB應用程序。