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

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

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

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

我正在开发一个有一些要求的 REST 服务：

1. 它必须是安全的。
2. 用户不应该能够伪造请求。

我目前提出的解决方案是有一个看起来像这样的自定义授权标头（这与亚马逊网络服务的工作方式相同）：

我的问题是如何形成签名。当用户登录服务时，他们会获得一个密钥，他们应该能够使用它来签署请求。这将阻止其他用户代表他们提交请求，但不会阻止他们伪造请求。

将使用此服务的应用程序是一个 iPhone 应用程序，所以我想我们可以在应用程序中嵌入一个公钥，我们可以用它来做一个额外的签名，但这是否意味着我们必须有两个签名，一个一个用户密钥和一个应用程序密钥？

任何建议将不胜感激，我很想第一次就做到这一点。

RESTful 身份验证是什么意思，它是如何工作的？我在 Google 上找不到很好的概述。我唯一的理解是您在 URL 中传递了会话密钥（remeberal），但这可能是非常错误的。

背景：

我正在为 REST Web 服务设计身份验证方案。这并不“真的”需要安全（它更像是一个个人项目），但我想让它尽可能安全，就像锻炼/学习体验一样。我不想使用 SSL，因为我不想要麻烦，而且主要是设置它的费用。

这些 SO 问题对我开始特别有用：

• RESTful 身份验证
• 保护 REST API/Web 服务的最佳实践
• 最佳 SOAP/REST/RPC Web API 的示例？你为什么喜欢他们？他们有什么问题？

我正在考虑使用简化版本的Amazon S3 身份验证（我喜欢OAuth，但它似乎对我的需求来说太复杂了）。我将服务器提供的随机生成的nonce添加到请求中，以防止重放攻击。

要解决这个问题：

S3 和 OAuth 都依赖于对请求 URL 以及一些选定的标头进行签名。他们都没有为 POST 或 PUT 请求签署请求正文。这是否容易受到中间人攻击，它保留 url 和 headers 并用攻击者想要的任何数据替换请求正文？

似乎我可以通过在签名的字符串中包含请求正文的哈希来防止这种情况。这安全吗？

我正在测试 WildFly 8.1 的 XXE 漏洞，我发现很烦人的事情。JAXB 默认使用安全解析和尊重entityExpansionLimit属性（默认为 64k）。由于它在 RestEasy 中的 Spring MVC 中工作，因此它被忽略（大扩展时崩溃服务器没有问题）。

有谁知道是否可以在 XXE 上保护 WildFly/RestEasy？我发现只支持 XML 外部实体保护 ( resteasy.document.expand.entity.references=false)

我正在（NodeJs / hapi）中开发一个api服务器以及一个android应用程序。我在理解如何通过 google 和 facebook 等第三方登录时遇到问题。

到目前为止，我的策略是：

1. 授权我的应用程序（安卓）
2. 从 google/facebook(android) 获取电子邮件和其他数据
3. 将电子邮件和数据发送到我的服务器并将其保存在数据库（服务器）中

下次认证的时候。我将根据保存数据（我的服务器）检查相同的数据（来自谷歌）。我很确定有更好的方法可以做到这一点，但是到目前为止我读过的文档让我很头疼。

帮助表示赞赏。

我有一个休息服务，我需要在使用 JS MVC 客户端框架（如 Backbone 或 Angular）的浏览器 Web 应用程序中使用它。但我需要确保我的休息服务不被暴露，否则其他人可能无法使用我的休息服务在任何设备/客户端上构建应用程序。早些时候，我曾想过使用身份验证凭据保护我的 Web 服务，并将其隐藏在代理后面，让代理提供 html 而不是服务。

但是我想知道如果我必须使用 ajax 调用直接从前端使用它，我该如何保护我的 Web 服务。

在我们公司，我们部署了多个使用 CAS 服务器通过 SSO 保护的 Web 应用程序。用户请求应用程序的 url，如果尚未通过身份验证，则会被重定向到 CAS 服务器登录页面。如果身份验证成功，用户将被重定向回最初请求的 url。共同的工作流程和完美的工作。

但是，我们还想使用 CAS 服务器保护我们的 REST API。我们的首选流程如下：

• 用户为应用程序 REST Api 创建令牌
• 使用此令牌，用户可以请求临时访问令牌（如 CAS 令牌）
• 在对 REST Api 的每个请求中，用户将临时访问令牌作为 HTTP 标头或请求参数包含在内
• REST Api 应用程序根据 CAS 服务器检查提供的临时令牌的有效性

听起来像 CAS 服务器确实支持的 OAuth，除了在任何时候都不会要求用户提供凭据，但我们还想为服务提供身份验证，即其他应用程序调用我们的 API：

• 开发人员要求提供 REST Api 令牌（与 CAS 用户相关联）
• 应用程序使用 Api 令牌请求临时访问令牌
• 对 Api 的进一步请求包括临时访问令牌作为 HTTP 标头或请求参数
• REST Api 应用程序根据 CAS 服务器检查临时访问令牌的有效性

我们希望我们的 REST Api 应用程序对用户凭据一无所知，他们甚至无法访问用户数据库，这对于使用应用程序的人来说工作得很好（重定向到 CAS 登录页面）。

我不知道我们如何实现这个流程，而不必大量定制 CAS 服务器并自己实现这个行为。

Google 使用 JWT for OAuth 2.0 for Server to Server Applications，这似乎是要走的路。

如果有人可以提供一些提示或替代方案（对 CAS 服务器），我将不胜感激。也许有人已经使用 CAS 服务器实现了这种模式，并且可以提供一些关于这个问题的信息。

最好的问候， 马可

我正在“Programming WCF Services”一书中阅读 WCF 的安全概念。由于点对点等，我得到了一般传输安全性对 Intranet 场景有好处的点。

对于互联网场景，我们可以选择消息安全作为更好的选择。我已经在基于 REST 的 wcf 的基础级别工作过。所以我使用 webHttpBinding。据我所知，消息安全性基于 WS 标准，而 webHttpBinding 是基于休息的，因此无法在 webHttpBinding 中应用消息安全性。

但是，如果采取像我在 REST wcf 中创建公共 API（用于互联网）这样的场景，因为这些方法也用于手持设备。这里传输安全性如何优于消息安全性。我的理解是正确的还是在 REST 传输安全是不同的概念？

请解释

当使用必须验证的电话号码执行身份验证时，如何处理 RESTful 身份验证？

例如，假设用户想要登录。用户将使用电话号码点击端点，然后将文本消息排队以发送到该电话号码以进行验证。

理论上，这两个端点可能如下所示：

身份验证 [POST /users/authentication]

使用电话号码查找或创建用户，返回该用户，并将要发送到指定电话号码的文本消息排入队列（延迟）。

• 请求（应用程序/json）

  /li>

• 响应 200（应用程序/json）

  /li>

组验证

用户提供在短信中发送的验证码，以验证请求身份验证的用户是否有效。

验证 [POST /users/{id}/verification]

• 请求（应用程序/json）

  /li>

• 响应 200（应用程序/json）

  /li>

以 RESTful 方式进行此验证的惯用方式是什么？动词正确吗？端点名称是否正确？我错过了什么吗？