保护 REST API/Web 服务的最佳实践 [英] Best Practices for securing a REST API / web service

问题描述

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

When designing a REST API or service are there any established best practices for dealing with security (Authentication, Authorization, Identity Management) ?

在构建 SOAP API 时，您将 WS-Security 作为指南，并且存在许多关于该主题的文献.我发现关于保护 REST 端点的信息较少.

When building a SOAP API you have WS-Security as a guide and much literature exists on the topic. I have found less information about securing REST endpoints.

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

While I understand REST intentionally does not have specifications analogous to WS-* I am hoping best practices or recommended patterns have emerged.

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

Any discussion or links to relevant documents would be very much appreciated. If it matters, we would be using WCF with POX/JSON serialized messages for our REST API's/Services built using v3.5 of the .NET Framework.

推荐答案

正如tweakt 所说，Amazon S3 是一个很好的模型.他们的请求签名确实具有一些功能(例如合并时间戳)，有助于防止意外和恶意请求重放.

As tweakt said, Amazon S3 is a good model to work with. Their request signatures do have some features (such as incorporating a timestamp) that help guard against both accidental and malicious request replaying.

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

The nice thing about HTTP Basic is that virtually all HTTP libraries support it. You will, of course, need to require SSL in this case because sending plaintext passwords over the net is almost universally a bad thing. Basic is preferable to Digest when using SSL because even if the caller already knows that credentials are required, Digest requires an extra roundtrip to exchange the nonce value. With Basic, the callers simply sends the credentials the first time.

一旦建立了客户端的身份，授权实际上只是一个实现问题.但是，您可以将授权委托给具有现有授权模型的其他组件.在这里，Basic 的另一个好处是，您的服务器最终会得到一份客户端密码的纯文本副本，您可以根据需要将其简单地传递给基础架构中的另一个组件.

Once the identity of the client is established, authorization is really just an implementation problem. However, you could delegate the authorization to some other component with an existing authorization model. Again the nice thing about Basic here is your server ends up with a plaintext copy of the client's password that you can simply pass on to another component within your infrastructure as needed.

这篇关于保护 REST API/Web 服务的最佳实践的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！