在设计REST API或者服务时，是否存在用于处理安全性(身份验证，授权，身份管理)的最佳实践？

在构建SOAP API时，我们以WS-Security为指南，并且有关该主题的文献很多。我发现有关保护REST端点的信息较少。

尽管我了解REST故意没有类似于WS- *的规范，但我希望出现了最佳实践或者推荐的模式。

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

解决方案

回答

除HTTP外，没有其他针对REST的标准。那里已经建立了REST服务。我建议我们看一看它们，并了解它们的工作原理。

例如，在开发自己的产品时，我们从Amazon的S3 REST服务中借用了很多想法。但是我们选择不使用基于请求签名的更高级的安全模型。更简单的方法是基于SSL的HTTP基本身份验证。我们必须决定哪种方法最适合情况。

另外，我强烈推荐O'reilly的书RESTful Web Services。它解释了核心概念，并提供了一些最佳实践。通常，我们可以采用他们提供的模型并将其映射到我们自己的应用程序。

回答

正如tweakt所说，Amazon S3是一个很好的模型。他们的请求签名确实具有一些功能(例如包含时间戳)，可以防止意外和恶意的请求重播。

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

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

回答

感谢出色建议。我们最终使用了一个自定义HTTP标头将身份令牌从客户端传递到服务，以准备将RESTful API与即将推出的Microsoft Zermatt Identity框架进行集成。我已经在这里描述了问题以及这里的解决方案。如果我们正在构建任何类型的RESTful API，我也接受了tweakt的建议，并购买了RESTful Web Services一本非常好的书。

回答

我们可能还想看看OAuth，这是一种新兴的开放协议，用于基于令牌的授权，专门针对http api。

它与flickr所采取的方法非常相似，请记住牛奶"休息" api(不一定是静态api的好例子，而是基于令牌的方法的好例子)。

回答

关于Rain的安全性方面，我见过的最好的帖子之一已于1 RainDrop结束。 MySpace API还将OAuth用于安全性，我们可以在RestChess代码中完全访问其自定义渠道，对此我进行了很多研究。这是在Mix上演示的，我们可以在此处找到发布内容。

回答

我使用过OAuth几次，还使用了其他一些方法(BASIC / DIGEST)。我全力建议OAuth。以下链接是我使用OAuth所见过的最好的教程：

http://hueniverse.com/oauth/guide/

回答

我很惊讶尚未提及带有客户端证书的SSL。当然，只有当我们可以依靠证书标识的用户社区时，这种方法才真正有用。但是许多政府/公司确实将它们发布给用户。用户不必担心会创建另一个用户名/密码组合，并且在每个连接上都建立了身份，因此与服务器的通信可以完全是无状态的，不需要用户会话。 (并不意味着提到的任何/所有其他解决方案都需要会话)