REST API安全目前的智慧狀態是什麼？

Question

我在網上收到有關首選REST API認證/授權機制的混合信號，特別是對於移動應用程序。

1. 有OAuth 1.0，但它聲稱比它需要更復雜，並且不太支持本地客戶（回調URL非常以瀏覽器爲中心）。另一方面，有一個主要的提供商支持它（Twitter）。
2. 然後是OAuth 2.0，它應該是1.0以上的改進，並且它在默認咒語中取代了客戶端加密（替換爲承載令牌），但有些人認爲it's broken by design和bearer tokens are no better than cookies。來自粗略提供商的SSL證書可以使移動客戶更容易相信該端點是可信的權威機構。不過，兩家主要提供商（Google和Facebook）都支持它。
3. 然後還有人，誰advocate sidestepping the whole mess and rolling your own.

因此，這是什麼呢？

Answer 1

這聽起來像是一個對衝，但答案是「任何適合您的應用程序」。

第三方身份驗證系統（如OAuth和OpenID）有自己的位置，它們非常適合某些應用程序，特別是那些允許客戶端成爲API用戶而無需將其個人憑據交付給另一個系統的系統服務器系統。

但是，您可能正在構建一個沒有該限制或要求的系統，並且可能有必要讓您的客戶在您的服務器上創建一個帳戶。在這種情況下，您可以通過使用HTTPS和基本身份驗證來大幅簡化事情。讓客戶端將他們的用戶名/密碼傳遞給適當的頭部，並確保您的連接受到SSL保護。或者，讓客戶使用證書作爲憑證。

我建議你首先列舉一下「安全」對你意味着什麼，並從頭開始工作。考慮每個相關方面，如完整性保證，不可否認性，重放保護，客戶端影響，性能和API可用性。從那裏，弄清楚你是否需要HTTPS /基本認證，或者你還需要添加API密鑰，OAuth，OpenID，校驗和等。

Answer 2

我建議使用OAuth 2，但需要額外的證書檢查客戶。如果您的證書來自Verisign，則使其他CA的所有證書無效。儘管如此，請務必始終在相同的CA上獲取證書，除非您喜歡分發更新。

但是，最終，只有客戶端可以驗證到服務器的連接是完全安全的。永遠別忘了。