保護REST API的典型建議是使用基於SSL的HTTP基本驗證。我的問題是，如果HTTP基本認證僅用於認證客戶端（即訪問該API的應用程序），還是它也可以用於認證用戶（該應用程序的消費者）？應該使用HTTP基本驗證進行客戶端驗證還是用戶API驗證？
似乎大多數API都必須處理這兩個問題，因爲幾乎所有的Web服務都使用某種用戶帳戶。只要考慮推特或Vimeo-有公共資源，並有私人（用戶特定）的資源。
一個簡單的REST API可以同時使用HTTP基本認證（通過SSL）執行客戶端和用戶認證似乎是合乎邏輯的。
這是一個很好的設計？
通過驗證客戶端，您可能意味着使用API密鑰，該機制用於跟蹤具體的應用程序/客戶端。第二件事是它可以通過禁用密鑰來禁用應用程序，例如當客戶的作者從服務中刪除他的帳戶時。如果你想公開你的API，那麼這是個好主意。
但是你需要記住，它沒有給你真正的保護，每個人都可以下載客戶端並提取該密鑰。
我不推薦使用基本身份驗證進行API身份驗證。當談到認證時，你應該考慮應用程序（客戶端）開發者也必須實現身份驗證的一面。其中一部分不僅僅是身份驗證本身，還包括如何獲取憑證，甚至遠不止於此。
我建議使用與最流行的編程語言的客戶端庫附帶的已建立的身份驗證標準。這些庫使得開發人員更有可能調整您的API，因爲他們減少了客戶端的實施工作。
使用身份驗證標準的另一個重要原因是它們使開發人員（和其他人）更加確信您的身份驗證系統的安全性。這些標準已經由專家進行了審計，並且其優點是衆所周知且記錄在案的。除非你是一位安全專家，否則你不太可能開發出接近一致的認證流程:-)。
該領域中最成熟的標準是OAuth，但您可以通過搜索「oauth alternatives」找到替代方案。
OAuth如何幫助您解決問題設置？
在OAuth 2中，應用程序客戶端在訪問任何受保護資源之前必須先爲用戶獲取訪問令牌。要獲取訪問令牌，應用程序必須使用其應用程序憑證對自身進行身份驗證。根據用例（例如第三方，移動設備）的不同，這可以通過OAuth標準定義的不同方式完成。
一個訪問令牌不僅應該代表一個用戶，而且還應該在哪些資源（權限）上使用哪些操作。用戶可以爲不同的應用程序授予不同的權限，因此必須以某種方式將該信息鏈接到令牌。
如何實現訪問令牌的語義但不是OAuth的一部分 - 它只是定義瞭如何獲取訪問令牌的流程。因此，訪問令牌語義的實現通常是特定於應用程序的。
您可以通過在創建訪問令牌時在後端存儲訪問令牌及其權限之間的鏈接來實現此類令牌語義。這些權限可以存儲在每個用戶應用程序組合中，也可以僅存儲在每個應用程序中，具體取決於您希望事情的細微程度。
然後，每次通過API處理訪問令牌時，都會獲取此信息並檢查用戶是否有足夠的權限訪問資源並執行所需的操作。
另一種選擇是將權限信息放入訪問令牌中並對令牌進行簽名或加密。當您收到訪問令牌時，您需要驗證或解密訪問令牌，並使用存儲在訪問令牌中的權限來做出決定。你可能想看看Json Web Tokens (JWT)關於如何做到這一點。
後端解決方案的好處是在後端實施期間具有更好的可伸縮性和更少的工作量。它的缺點是潛在的更大的請求（特別是RSA加密）和對令牌的控制較少。