无需重新发明轮子即可保护 REST API [英] Securing REST API without reinventing the wheel
问题描述
在设计 REST API 时，通常先对用户进行身份验证吗?
When designing REST API is it common to authenticate a user first?
我正在寻找的典型用例是:
The typical use case I am looking for is:
- 用户想要获取数据.当然很酷，我们喜欢分享！获取公共 API 密钥并开始阅读！
- 用户想要存储/更新数据...哇等等！你是谁，你能做到吗?
我想构建一次并允许说一个网络应用程序、一个安卓应用程序或一个 iPhone 应用程序来使用它.
I would like to build it once and allow say a web-app, an android application or an iPhone application to use it.
REST API 似乎是具有此类要求的合乎逻辑的选择
A REST API appears to be a logical choice with requirements like this
为了说明我的问题，我将使用一个简单的例子.
To illustrate my question I'll use a simple example.
我在数据库中有一个项目，它有一个 rating 属性(整数 1 到 5).
I have an item in a database, which has a rating attribute (integer 1 to 5).
如果我正确理解 REST，我将使用我选择的语言实现 GET 请求，返回 csv、xml 或 json，如下所示:
If I understand REST correctly I would implement a GET request using the language of my choice that returns csv, xml or json like this:
http://example.com/product/getrating/{id}/
假设我们选择返回的 JSON:
Say we pick JSON we return:
{
"id": "1",
"name": "widget1",
"attributes": { "rating": {"type":"int", "value":4} }
}
这适用于面向公众的 API.我知道那部分.
This is fine for public facing APIs. I get that part.
我有很多问题是如何将其与安全模型结合起来?我习惯于网络应用程序安全性，其中我有一个会话状态始终标识我的用户，因此无论他们决定向我发送什么，我都可以控制他们可以做什么.据我了解，这不是 RESTful，因此在这种情况下将是一个糟糕的解决方案.
Where I have tons of question is how do I combine this with a security model? I'm used to web-app security where I have a session state identifying my user at all time so I can control what they can do no matter what they decide to send me. As I understand it this isn't RESTful so would be a bad solution in this case.
我将尝试使用另一个使用相同项目/评级的示例.
I'll try to use another example using the same item/rating.
如果用户JOE"想要为项目
If user "JOE" wants to add a rating to an item
这可以使用:
http://example.com/product/addrating/{id}/{givenRating}/
此时我想存储数据，说明JOE"给产品 {id} 的评级为 {givenRating}.
At this point I want to store the data saying that "JOE" gave product {id} a rating of {givenRating}.
问题:我怎么知道请求来自JOE"而不是BOB".
Question: How do I know the request came from "JOE" and not "BOB".
此外，如果是用户电话号码等更合理的数据呢?
Furthermore, what if it was for more sensible data like a user's phone number?
到目前为止我得到的是:
What I've got so far is:
1) 使用 HTTP 的内置功能对每个请求进行身份验证，无论是纯 HTTP 还是 HTTPS.
1) Use the built-in feature of HTTP to authenticate at every request, either plain HTTP or HTTPS.
这意味着现在每个请求都采用以下形式:
This means that every request now take the form of:
https://joe:joepassword@example.com/product/addrating/{id}/{givenRating}/
2) 使用带有私钥和公钥的 Amazon S3 之类的方法:http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
2) Use an approach like Amazon's S3 with private and public key: http://www.thebuzzmedia.com/designing-a-secure-rest-api-without-oauth-authentication/
3) 无论如何都要使用 cookie 并打破 REST 的无状态部分.
3) Use a cookie anyway and break the stateless part of REST.
第二种方法对我来说似乎更好，但我想知道我真的必须重新发明整个事情吗?散列，存储，生成密钥等都是我自己吗?
The second approach appears better to me, but I am left wondering do I really have to re-invent this whole thing? Hashing, storing, generating the keys, etc all by myself?
这听起来很像在典型的 Web 应用程序中使用 session 并自己重写整个堆栈，这对我来说通常意味着你做错了"，尤其是在处理安全问题时.
This sounds a lot like using session in a typical web application and rewriting the entire stack yourself, which usually to me mean "You're doing it wrong" especially when dealing with security.
我想我也应该提到 OAuth.
I guess I should have mentioned OAuth as well.
推荐答案
5 年后编辑
使用 OAuth2！
以前的版本
不，绝对没有必要使用 cookie.它的安全性不如 HTTP Digest、OAuth 或亚马逊的 AWS(不难复制).
No, there is absolutely no need to use a cookie. It's not half as secure as HTTP Digest, OAuth or Amazon's AWS (which is not hard to copy).
您应该看待 cookie 的方式是，它是一个身份验证令牌，与 Basic/Digest/OAuth/无论哪个一样，但不太合适.
The way you should look at a cookie is that it's an authentication token as much as Basic/Digest/OAuth/whichever would be, but less appropriate.
但是，我不觉得使用 cookie 违背 RESTful 原则本身，只要会话 cookie 的内容不影响您从 RESTful 返回的资源的内容服务器.
However, I don't feel using a cookie goes against RESTful principles per se, as long as the contents of the session cookie does not influence the contents of the resource you're returning from the server.
Cookie 是邪恶的，停止使用它们.
Cookies are evil, stop using them.
这篇关于无需重新发明轮子即可保护 REST API的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
