我在EMC上的一個平臺上可以構建SaaS解決方案。

與越來越多的其他應用程序一樣，該平臺具有基于RESTful HTTP的API。

使用像JAX-RS這樣的開發框架，構建這樣的API相對容易。

但是， 正確構建它們并不容易。

建立基于HTTP的API的問題

問題不僅僅在于功能的發布。 我們知道如何開發軟件 ，可用的REST / HTTP框架和庫使公開功能變得容易。

但是，這只是故事的一半。 還有更多的-ilities考慮。

在REST架構風格解決其中的一些，如可擴展性和進化能力 。

如今，許多基于HTTP的API都聲稱是RESTful的，但實際上不是 。 這意味著他們沒有獲得REST可以帶來的所有好處。

在以后的文章中，我將更多地討論如何幫助開發人員滿足REST體系結構風格的所有限制。

今天，我想著重介紹API的另一個非功能性方面： 安全性 。

基于HTTP的API的安全性

在安全方面，我們關心CIA-triad： 機密性 ， 完整性和可用性 。

Web服務的可用性與Web應用程序的可用性并沒有很大的不同，這是眾所周知的。 我們有集群，負載均衡器，而沒有什么， 通常我們的狀態很好。

另一方面，機密性和完整性都需要正確的身份驗證 ，在這里事情變得更加有趣。

基于HTTP的API的身份驗證

對于HTTP世界中的身份驗證 ，請看一下HTTP Authentication 。

該RFC描述了基本身份驗證和摘要身份驗證。 兩者都有缺點 ，這就是為什么您看到許多API使用替代方法的原因。

幸運的是，這些替代方案可以使用RFC中定義的相同基本機制。 該機制包括狀態碼401 Unauthorized以及WWW-Authenticate ， Authentication-Info和Authorization標頭。 請注意，不幸的是， Authorization標頭的名稱錯誤，因為它用于身份驗證，而不是authorization 。

最后一個難題是自定義身份驗證方案 。 例如， Amazon S3身份驗證使用AWS自定義方案。

使用簽名對基于HTTP的API進行身份驗證

AWS方案依賴于簽名 。 其他服務（例如EMC Atmos ）也使用相同的方法。

因此，很高興看到已經提出了新的IETF草案以標準化基于HTTP的API中簽名的使用。

標準化使框架和庫的構建成為可能，這將降低實現身份驗證的成本，并使構建更安全的API更容易。

參考： 安全軟件開發博客上的JCG合作伙伴 Remon Sinnema提供的參考文獻： 使用簽名保護基于HTTP的API 。

翻譯自: https://www.javacodegeeks.com/2013/08/securing-http-based-apis-with-signatures.html

總結

以上是生活随笔為你收集整理的使用签名保护基于HTTP的API的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。