在不重新发明轮子的情况下保护REST API

Question

设计REST API时,首先对用户进行身份验证是否常见？

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

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

我想建立一次,并允许说一个Web应用程序,一个Android应用程序或iPhone应用程序来使用它.

REST API似乎是符合此要求的逻辑选择

为了说明我的问题,我将使用一个简单的例子.

我在数据库中有一个项目,它有一个rating属性(整数1到5).

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

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:joepassword@example.com/product/addrating/{id}/{givenRating}/

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

3)无论如何使用cookie并打破REST的无状态部分.

第二种方法对我来说似乎更好,但我想知道我真的需要重新发明这一切吗？所有由我自己进行哈希,存储,生成密钥等等？

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

编辑:我想我也应该提到OAuth.

Answer 1

不要担心"RESTful",担心安全性.我是这样做的:

步骤1:用户使用凭据命中身份验证服务.

步骤2:如果凭据签出,返回指纹,会话ID等,并将其弹出到共享内存中以便以后快速检索,或者如果您不介意在Web服务周转时间内添加几毫秒,请使用数据库.

步骤3:在每个Web服务脚本的顶部添加一个入口点调用,以验证每个 Web服务请求的指纹和会话ID .

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

读这个:

RESTful身份验证

Answer 2

5年后编辑

使用OAuth2!

以前的版本

不,绝对不需要使用cookie.它不像HTTP摘要,OAuth或亚马逊的AWS那样安全一半(不难复制).

你应该看一个cookie的方式是它是一个身份验证令牌,就像Basic/Digest/OAuth /那样,但不太合适.

但是,我不认为使用cookie 本身就违反RESTful原则,只要会话cookie的内容不影响您从服务器返回的资源的内容.

饼干是邪恶的,停止使用它们.

Answer 3

编辑3年后

我完全同意Evert,使用OAuth2和HTTPS,并且不要重新发明轮子!:-)

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

以前的版本

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

不要使用会话,对于会话,您的REST服务将无法很好地扩展......这里有2个状态:应用程序状态(或客户端状态或会话)和资源状态.应用程序状态包含会话数据,由REST客户端维护.资源状态包含资源属性和关系,由REST服务维护.您可以非常轻松地决定特定变量是应用程序状态还是资源状态的一部分.如果数据量随活动会话数增加,则它属于应用程序状态.因此,例如当前会话的用户身份属于应用程序状态,但是用户列表或用户权限属于资源状态.

因此,REST客户端应存储标识因子并随每个请求发送它们.不要将REST客户端与HTTP客户端混淆.他们不一样.如果REST客户端使用curl,它也可以在服务器端,或者它可以创建例如服务器端仅http的cookie,它可以通过CORS与REST服务共享.唯一重要的是REST服务必须通过每个请求进行身份验证,因此您必须在每个请求中发送凭据(用户名,密码).

• 如果您编写客户端REST客户端,则可以使用SSL + HTTP身份验证来完成此操作.在这种情况下,您可以credentials -> (identity, permissions)在服务器上创建缓存以更快地进行身份验证.请注意,如果您清除该缓存,并且用户发送相同的请求,他们将得到相同的响应,只需要更长的时间.您可以将其与会话进行比较:如果清除会话存储,则用户将收到status: 401 unauthorized响应...
• 如果您编写服务器端REST客户端并通过curl将标识因子发送到REST服务,那么您有2个选择.您也可以使用http auth,或者您可以在REST客户端中使用会话管理器,但不能在REST服务中使用.
• 如果某人不信任写入您的REST客户端,那么您必须编写一个应用程序来对用户进行身份验证,并为他们提供可用性,以决定他们是否要向不同的客户端授予权限.Oauth已经是现有的解决方案.Oauth1更安全,oauth2安全性更低但更简单,我想还有其他一些解决这个问题的方法......你不必重新发明这个.使用oauth有完整的身份验证和授权解决方案,例如:wso身份服务器.

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