REST风格的认证 [英] RESTful Authentication

问题描述

什么是REST风格的认证意味着，它是如何工作的？我找不到在谷歌很好的概述。我唯一​​的理解是，你通过在URL中的会话密钥（remeberal），但是这可能是可怕的错误。

What does RESTful Authentication mean and how does it work? I can't find a good overview on Google. My only understanding is that you pass the session key (remeberal) in the URL, but this could be horribly wrong.

推荐答案

如何在REST风格的客户端 - 服务器架构处理身份验证是一个见仁见智的问题。

How to handle authentication in a RESTful Client-Server architecture is a matter of debate.

通常，可以通过HTTP世界通过实现，在SOA：

Commonly, it can be achieved, in the SOA over HTTP world via:

• HTTP基本身份验证通过HTTPS;


• Cookies和会话管理;


• 令牌在HTTP头（例如的OAuth 的2.0）;


• 查询认证附加签名的参数。

• HTTP basic auth over HTTPS;
• Cookies and session management;
• Token in HTTP headers (e.g. OAuth 2.0);
• Query Authentication with additional signature parameters.

您将不得不去适应，甚至更好的搭配这些技术，以最适合您的软件架构。

You'll have to adapt, or even better mix those techniques, to match your software architecture at best.

每个认证方案都有自己的优点和缺点，这取决于您的安全策略和软件体系结构的目的。

Each authentication scheme has its own PROs and CONs, depending on the purpose of your security policy and software architecture.

HTTP基本身份验证通过HTTPS

这第一个解决方案，基于标准的HTTPS协议，所使用的大多数Web服务。

This first solution, based on the standard HTTPS protocol, is used by most web services.

GET /spec.html HTTP/1.1
Host: www.example.org
Authorization: Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==

这很容易实现，可以在默认情况下所有的浏览器，但有一些已知的平局中后卫，就像在浏览器中显示的可怕的认证窗口，这将持续（没有注销般的功能在这里），一些服务器 - 侧额外的CPU消耗，以及用户名和密码传输（通过HTTPS）的事实到服务器（它应该是更安全，让密码只停留在客户端，键盘输入过程中，并存储为安全哈希在服务器上）。

It's easy to implement, available by default on all browsers, but has some known draw-backs, like the awful authentication window displayed on the Browser, which will persist (there is no LogOut-like feature here), some server-side additional CPU consumption, and the fact that the user-name and password are transmitted (over HTTPS) into the Server (it should be more secure to let the password stay only on the client side, during keyboard entry, and be stored as secure hash on the Server).

我们可以使用摘要式身份验证，但它也需要HTTPS，因为它是容易的的MiM 或重播攻击，是针对HTTP。

We may use Digest Authentication, but it requires also HTTPS, since it is vulnerable to MiM or Replay attacks, and is specific to HTTP.

通过cookie会话

说实话，在服务器上管理的会话不是真正的无状态的。

To be honest, a session managed on the Server is not truly Stateless.

一种可能是维持该cookie内容之内的所有数据。而且，在设计上，该cookie将被在服务器端进行处理（客户端其实也甚至没有尝试跨preT这个cookie数据：它只是手回服务器上的每个连续的要求）。但这种cookie数据是应用程序状态数据，所以客户应该管理它，而不是服务器，在一个纯粹的无状态的世界。

One possibility could be to maintain all data within the cookie content. And, by design, the cookie is handled on the Server side (Client in fact does even not try to interpret this cookie data: it just hands it back to the server on each successive request). But this cookie data is application state data, so the client should manage it, not the server, in a pure Stateless world.

GET /spec.html HTTP/1.1
Host: www.example.org
Cookie: theme=light; sessionToken=abc123

该Cookie技术本身是HTTP连接，所以它不是真正的REST风格，这应该是独立于协议的，恕我直言。它很容易受到的MiM 或的重播攻击。

通过令牌（OAuth2用户）授予

另一种方法是把HTTP头中的标记，使得该请求被认证。这是什么的的OAuth 的2.0呢，例如。请参见的RFC 6749 ：

An alternative is to put a token within the HTTP headers, so that the request is authenticated. This is what OAuth 2.0 does, for instance. See the RFC 6749:

 GET /resource/1 HTTP/1.1
 Host: example.com
 Authorization: Bearer mF_9.B5f-4.1JqM

总之，这是非常相似的一个cookie，并遭受相同的问题：不是无状态，依赖于HTTP传输的详细信息，并受的很多安全缺陷的 - 包括的MiM和重播 - 所以只能通过HTTPS使用

In short, this is very similar to a cookie, and suffers to the same issues: not stateless, relying on HTTP transmission details, and subject to a lot of security weaknesses - including MiM and Replay - so is to be used only over HTTPS.

查询验证

查询验证由签署通过的URI一些额外的参数每个REST风格的请求。见<一href=\"http://broadcast.oreilly.com/2009/12/principles-for-standardized-rest-authentication.html\">this参考文章。

Query Authentication consists in signing each RESTful request via some additional parameters on the URI. See this reference article.

据本文中定义为这样的：

It was defined as such in this article:

所有的REST查询必须通过签订查询参数进行身份验证
  分类小写字母顺序使用专用凭证
  作为签约令牌。签名应该出现URL编码前
  查询字符串。

All REST queries must be authenticated by signing the query parameters sorted in lower-case, alphabetical order using the private credential as the signing token. Signing should occur before URL encoding the query string.

此技术可能是用无状态架构更加相容，并且还可以与一个光会话管理（使用内存中的会话，而不是块的持久性）来实现。

This technique is perhaps the more compatible with a Stateless architecture, and can also be implemented with a light session management (using in-memory sessions instead of DB persistence).

例如，这里是从上面的链接一个通用的URI示例：

For instance, here is a generic URI sample from the link above:

GET /object?apiKey=Qwerty2010

应该这样来传送：

should be transmitted as such:

GET /object?timestamp=1261496500&apiKey=Qwerty2010&signature=abcdef0123456789

签字的字符串是 /对象apikey = Qwerty2010＆放大器;时间戳= 1261496500 和签名是使用API​​密钥的私有组件该字符串的SHA256哈希值。

The string being signed is /object?apikey=Qwerty2010&timestamp=1261496500 and the signature is the SHA256 hash of that string using the private component of the API key.

服务器端数据缓存可以始终可用。例如，在我们的框架内，我们缓存响应在SQL级，而不是在该URI水平。因此，添加此额外的参数不破的缓存机制。

Server-side data caching can be always available. For instance, in our framework, we cache the responses at the SQL level, not at the URI level. So adding this extra parameter doesn't break the cache mechanism.

请参阅这篇文章有关REST风格的认证的一些细节我们客户端 - 服务器ORM / SOA / MVC框架，基于JSON和REST。既然我们允许通信不仅通过HTTP / 1.1，还命名管道或GDI消息（本地），我们试图实现一个真正的RESTful的身份验证模式，而不是依赖于HTTP特殊性（如头部或饼干）。

See this article for some details about RESTful authentication in our client-server ORM/SOA/MVC framework, based on JSON and REST. Since we allow communication not only over HTTP/1.1, but also named pipes or GDI messages (locally), we tried to implement a truly RESTful authentication pattern, and not rely on HTTP specificity (like header or cookies).

在实践中，即将到来的 MAC令牌身份验证的OAuth 2.0 可能是对于通过令牌授予目前计划一个巨大的进步。但是，这仍然是一个进展中的工作，是依赖于HTTP传输。

In practice, the upcoming MAC Tokens Authentication for OAuth 2.0 may be a huge improvement in respect to the "Granted by Token" current scheme. But this is still a work in progress, and is tied to HTTP transmission.

结论

这是值得得出的结论是REST不仅是基于HTTP的，即使在实践中，它主要实现通过HTTP。 REST可以使用其他通信层。所以，一个RESTful认证不仅是一个HTTP验证，无论谷歌的答案代名词。它甚至不应该使用在所有的HTTP机制，但应与通信层抽象。

It's worth concluding that REST is not only HTTP-based, even if, in practice, it's mostly implemented over HTTP. REST can use other communication layers. So a RESTful authentication is not just a synonym of HTTP authentication, whatever Google answers. It should even not use the HTTP mechanism at all, but shall be abstracted from the communication layer.

这篇关于REST风格的认证的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！