使用签名保护基于HTTP的API

我在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