确保 REST API 安全，无需重新发明轮子

Question

在设计 REST API 时，通常首先对用户进行身份验证吗？

我正在寻找的典型用例是：

• 用户想要获取数据。当然很酷，我们喜欢分享！获取公共 API 密钥并阅读！
• 用户想要存储/更新数据...哇等等！你是谁，你能做到吗？

我想构建一次并允许 Web 应用程序、Android 应用程序或 iPhone 应用程序使用它。

REST API 似乎是满足这样的要求的逻辑选择

为了说明我的问题，我将使用一个简单的示例。

我的数据库中有一个项目，它具有 评级 属性（整数 1 到 5）。

如果我正确理解 REST，我将使用我选择的返回 csv、xml 或 json 的语言实现 GET 请求，如下所示：

http://example.com/product/getrating/{id}/

假设我们选择返回的 JSON：

{
  "id": "1",
  "name": "widget1",
  "attributes": { "rating": {"type":"int", "value":4} }
}

这对于面向公众的 API 来说很好。我明白那部分。

我有很多问题是如何将其与安全模型结合起来？我习惯了网络应用程序安全性，我有一个会话状态可以随时识别我的用户，这样我就可以控制他们可以做什么，无论他们决定向我发送什么。据我了解，这不是 RESTful，所以在这种情况下这将是一个糟糕的解决方案。

我将尝试使用另一个使用相同项目/评级的示例。

如果用户“JOE”想要向项目添加评级，

可以使用以下方法完成：

http://example.com/product/addrating/{id}/{givenRating}/

此时，我想存储“JOE”给出产品{的数据id} 评分为 {givenRating}。

问题：我如何知道请求来自“JOE”而不是“BOB”。

此外，如果是为了更敏感的数据（例如用户的电话号码）怎么办？

到目前为止我所得到的是：

1) 使用 HTTP 的内置功能对每个请求进行身份验证，无论是纯 HTTP 还是 HTTPS。

这意味着现在每个请求都采用以下形式：

https://joe:[email protected]/product/addrating/{id}/{givenRating}/

2) 使用 Amazon S3 等带有私钥和公钥的方法： http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/

3）无论如何都使用cookie并打破无状态部分休息。

第二种方法对我来说似乎更好，但我想知道我是否真的必须重新发明整个事情？散列、存储、生成密钥等全部由我自己完成吗？

这听起来很像在典型的 Web 应用程序中使用会话并自己重写整个堆栈，这对我来说通常意味着“你做错了”，尤其是在处理安全性时。

编辑：我想我也应该提到 OAuth。

Answer 1

5年后编辑

使用OAuth2！

以前的版本

不，绝对不需要使用cookie。它的安全性还不及 HTTP Digest、OAuth 或 Amazon 的 AWS（这并不难复制）。

您应该看待 cookie 的方式是，它与 Basic/Digest/OAuth/ 中的任何一个一样都是身份验证令牌，但不太合适。

不过，我不认为使用 cookie 本身就违反了 RESTful 原则，只要会话 cookie 的内容不会影响从服务器返回的资源内容即可。

Cookie 是邪恶的，停止使用它们。

Answer 2

不要担心“RESTful”，担心安全。我是这样做的：

第 1 步：用户使用凭据访问身份验证服务。

第 2 步：如果凭据签出，则返回指纹、会话 ID 等...，并将它们弹出到共享内存中以便稍后快速检索，或者如果您不介意在 Web 服务周转时间上增加几毫秒，则使用数据库。

步骤 3：将入口点调用添加到每个 Web 服务脚本的顶部，以验证每个 Web 服务请求的指纹和会话 ID。

步骤 4：如果指纹和会话 ID 无效或超时，则重定向到身份验证。

阅读本文：

RESTful 身份验证

Answer 3

3年后编辑

我完全同意Evert的观点，使用OAuth2和HTTPS，并且不要重新发明轮子！ :-)

通过更简单的 REST API - 不适用于第 3 方客户端 - JSON Web 令牌 也可以很好。

以前的版本

无论如何都要使用 cookie 并打破 REST 的无状态部分。

不要使用会话，使用会话，您的 REST 服务将无法很好地扩展...这里有 2 种状态：应用程序状态（或客户端状态或会话）和资源状态。应用程序状态包含会话数据，由 REST 客户端维护。资源状态包含资源属性和关系，由 REST 服务维护。您可以非常轻松地决定特定变量是应用程序状态还是资源状态的一部分。如果数据量随着活动会话数的增加而增加，那么就属于应用程序状态。例如，当前会话的用户身份属于应用程序状态，但用户或用户权限的列表属于资源状态。

因此，REST 客户端应该存储标识因素并在每次请求时发送它们。不要将 REST 客户端与 HTTP 客户端混淆。它们不一样。如果 REST 客户端使用curl，它也可以位于服务器端，或者它可以创建一个服务器端仅 http 的 cookie，它可以通过 CORS 与 REST 服务共享。唯一重要的是 REST 服务必须对每个请求进行身份验证，因此您必须在每个请求中发送凭据（用户名、密码）。

• 如果您编写客户端 REST 客户端，则可以使用 SSL + HTTP 身份验证来完成。在这种情况下，您可以创建一个凭据 -> （身份，权限）缓存在服务器上以使身份验证更快。请注意，如果清除该缓存，并且用户发送相同的请求，他们将得到相同的响应，只是需要更长的时间。您可以将其与会话进行比较：如果您清除会话存储，则用户将收到状态：401未经授权响应...
• 如果您编写服务器端REST客户端并向REST发送识别因素通过curl提供服务，那么你有2个选择。您也可以使用 http 身份验证，或者可以在 REST 客户端中使用会话管理器，但不能在 REST 服务中使用。
• 如果某个不受信任的人编写了您的 REST 客户端，那么您必须编写一个应用程序来对用户进行身份验证，并让他们可以决定是否向不同的客户端授予权限。 Oauth 是一个现有的解决方案。 Oauth1 更安全，oauth2 安全性较差但更简单，我想这个问题还有其他几种解决方案......您不必重新发明这个。使用 oauth 有完整的身份验证和授权解决方案，例如：wso 身份服务器。

饼干不一定是坏事。您可以以 RESTful 方式使用它们，直到它们保存客户端状态并且服务仅保存资源状态。例如，您可以将购物车或首选分页设置存储在 cookie 中...