在设计REST API或服务时,是否有处理安全性(身份验证、授权、身份管理)的最佳实践?

在构建SOAPAPI时,您可以将WS-Security作为指南,并且有许多关于该主题的文献。我发现关于保护REST端点的信息较少。

虽然我理解REST故意没有类似于WS-*的规范,但我希望已经出现了最佳实践或推荐的模式。

如有任何讨论或相关文件的链接,我们将不胜感激。如果重要的话,我们将使用WCF和POX/JSON序列化消息,用于使用.NET Framework v3.5构建的REST API/服务。


当前回答

谢谢你的忠告。我们最终使用了一个定制的HTTP头将身份令牌从客户端传递给服务,为将RESTful API和微软即将推出的Zermatt identity框架集成做准备。我已经在这里描述了问题和我们的解决方案。我还采纳了tweet的建议,购买了RESTfulWebServices——如果你正在构建任何类型的RESTfulAPI,这是一本非常好的书。

其他回答

OWASP(开放Web应用程序安全项目)有一些涉及Web应用程序开发各个方面的备忘单。本项目是非常有价值和可靠的信息来源。关于REST服务,您可以检查:https://www.owasp.org/index.php/REST_Security_Cheat_Sheet

我想添加(与臭马特一致),最简单的解决方案是将SSL证书添加到您的站点。换句话说,确保您的url是HTTPS://。这将保障你的交通安全(一掷千金)。使用RESTfulurl,想法是保持它的简单性(不像WS*security/SAML),您可以使用oAuth2/openID连接,甚至可以使用Basic Auth(在简单的情况下)。但您仍然需要SSL/HTTPS。请在此处检查ASP.NET Web API 2安全性:http://www.asp.net/web-api/overview/security(文章和视频)

我推荐OAuth 2/3。更多信息请访问http://oauth.net/2/

正如twitt所说,AmazonS3是一个很好的模型。它们的请求签名确实具有一些特性(如包含时间戳),有助于防止意外和恶意请求重放。

HTTP Basic的优点是几乎所有的HTTP库都支持它。当然,在这种情况下,您需要使用SSL,因为通过网络发送明文密码几乎是一件普遍的坏事。使用SSL时,Basic比Digest更好,因为即使调用方已经知道需要凭据,Digest也需要额外的往返来交换nonce值。使用Basic,调用者只需在第一次发送凭证。

一旦确定了客户机的身份,授权实际上只是一个实现问题。但是,您可以将授权委托给具有现有授权模型的其他组件。同样,Basic的好处是,您的服务器最终提供了客户端密码的明文副本,您可以根据需要将其传递给基础架构中的另一个组件。

我搜索了很多关于restful ws安全性的信息,最后我们通过cookie在客户端到服务器之间使用令牌来验证请求。我使用spring安全性来授权服务中的请求,因为我必须根据DB中已经存在的指定安全策略来验证和授权每个请求。