通過REST API進行身份驗證並保護API本身

Question

我已經使用Jersey 2.x為我的應用程序實現了REST API。 我采用REST方法是因為我計划在以后添加移動應用程序。 目前，這只是一個網絡應用。 我正在考慮安全性。 我需要處理兩件事。

1. 驗證和授權用戶：現在，我正在通過HTTP使用HTTP Basic身份驗證。 但是有沒有一種更好的方法，而不是讓用戶通過網絡發送用戶名和密碼。 我了解它是通過HTTPS進行的，但我正在探索。 OAuth 1.0a浮現在腦海。 我在正確的軌道上嗎？
2. 確保API本身的安全：除了我的Web應用程序之外，我不希望其他任何客戶端出現在白名單中。 稍后，我將移動應用程序添加到此白名單中。 我正在想象某種識別此客戶的秘密密鑰？

我想上面的＃1和＃2都可以使用OAuth 1.0a來完成，但就安全性和授權性而言，它們是兩種不同的實現。 他們可以共存嗎？ 您能為我提供有關入門的任何指示以及現實世界中的一些示例嗎？

那里有很多信息，但是安全性不是我的強項，我試圖通過自己在自己的應用程序中進行編碼來理解。

Answer 1

我的第一個建議是讓您研究OAuth 2.0，我不打算討論它比OAuth 1.0a更好還是更壞，但是它似乎得到了更廣泛的采用，因此，您將更容易找到資源線上; OAuth2還將許多安全功能存儲在HTTPS的肩膀上，您似乎已經在使用它。

關於將HTTP Basic身份驗證與OAuth2進行比較，我將檢查此答案的一些優缺點，但從整體上看：

使用基本身份驗證，完整的憑據始終包含在每個請求中，而使用OAuth2，則是每個請求中包含的訪問令牌。

關於使用密鑰識別每個客戶端應用程序，OAuth2確實支持此功能，但是，如果您計划使用（本機）移動應用程序，那么您將面臨巨大的挑戰，因為這些應用程序無法真正保留機密（攻擊者可以對您的應用程序進行反向工程並找到秘訣）。

總之，對於傳統的Web應用程序而言，很容易確保您的API僅允許訪問確實使用您列入白名單的應用程序的授權用戶 。 如果您想對本機移動應用程序打開API， 您將很難證明調用確實來自您授權的應用程序之一 。

有關常見OAuth2方案的示例，我將檢查Auth0體系結構方案 。