使用OAuth2.0保護Web Api

Question

我已經瞭解到OAuth 2.0委派了訪問控制。我想在這裏問一下OAuth2.0客戶端憑據授權流程（http://oauthlib.readthedocs.io/en/latest/oauth2/grants/credentials.html） 。當我讀到這個流程時，它允許客戶端應用程序在目標服務（web api）的控制下（客戶端應用程序擁有的資源）訪問資源。例如，在Google服務的情況下 - 客戶端應用程序可能想要檢索擁有的Blob數據由Google Blob Storage提供。

但我看到有人使用此流程進行客戶端和服務應用程序之間的身份驗證（而非授權）。例如有一個Web API，它爲一些公開的數據提供服務，而不是由特定的客戶端APP擁有。而這項服務只能由少數衆所周知的客戶端應用程序來調用。 （因此，新客戶端應用程序在獲得訪問權之前需要經過適當的入門過程）。

因此，在這種情況下，易於使用OAuth 2.0客戶端憑證流程。或者僅當客戶端應用程序想要訪問自己的資源時才適用。

Answer 1

爲了您的目的，可以使用Client Credentials Flow，但是Basic Authentication更簡單。您不必使用OAuth 2.0。

但是，請記住，如果客戶端應用程序不能保持客戶端憑證兩種解決方案不應該使用（= CLIENT_ID和OAuth 2.0用戶境客戶端祕密，API密鑰和API祕密基本身份驗證上下文）機密。以下是摘自RFC 6749,4.4. Client Credentials Grant的摘錄。

客戶端憑證授予類型務必只能用於機密客戶端。

可以在RFC 6749找到機密客戶的定義。

---

加了註釋：

蠻力攻擊可能會無論你使用基本身份驗證或OAuth的。關於可擴展性，（1）檢查一對API密鑰和祕密的有效性和（2）檢查訪問令牌的有效性之間沒有很大區別。

您可以在OAuth 1.0（RFC 5849）中找到「請求籤名」的概念，但規範已廢棄。有些人仍然認爲OAuth 1.0在安全性方面優於OAuth 2.0，但應該注意的是，OAuth 1.0的安全性依賴於嵌入在客戶端應用程序中的密鑰可以保密的假設。但是，這個假設是天真的。有關「How is OAuth 2 different from OAuth 1?」的問題，請參閱my answer。

OpenID Connect，一個相對較新並建議規範，定義了一個請求的簽名和加密，太。您可以在OpenID Connect Core 1.0的「6. Passing Request Parameters as JWTs」中找到它。