RESTful 认证 [英] RESTful Authentication

问题描述

RESTful 身份验证是什么意思，它是如何工作的?我在谷歌上找不到很好的概述.我唯一的理解是您在 URL 中传递了会话密钥(记住)，但这可能是非常错误的.

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.

推荐答案

如何在 RESTful 客户端-服务器架构中处理身份验证是一个有争议的问题.

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

通常，它可以通过以下方式在 SOA over HTTP 世界中实现:

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

• 基于 HTTPS 的 HTTP 基本身份验证；
• Cookie 和会话管理；
• HTTP 标头中的令牌(例如 OAuth 2.0 + JWT)；
• 使用其他签名参数查询身份验证.

• HTTP basic auth over HTTPS;
• Cookies and session management;
• Token in HTTP headers (e.g. OAuth 2.0 + JWT);
• 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.

基于 HTTPS 的 HTTP 基本身份验证

第一个解决方案基于标准 HTTPS 协议，被大多数网络服务使用.

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 drawbacks, 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 在服务器端处理(实际上，客户端甚至不会尝试解释此 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 链接的，所以它不是真正的 RESTful，它应该是独立于协议的，恕我直言.它容易受到 MiM 或 重放 攻击.

The cookie technique itself is HTTP-linked, so it's not truly RESTful, which should be protocol-independent, IMHO. It is vulnerable to MiM or Replay attacks.

通过令牌 (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 和 Replay - 所以只能通过 HTTPS 使用.通常，JWT 用作令牌.

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. Typically, a JWT is used as a token.

查询认证

查询身份验证包括通过 URI 上的一些附加参数对每个 RESTful 请求进行签名.请参阅这篇参考文章.

Query Authentication consists in signing each RESTful request via some additional parameters on the URI. See this reference 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

应该这样传输:

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

被签名的字符串是 /object?apikey=Qwerty2010&timestamp=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.

请参阅这篇文章我们的客户端-服务器 ORM/SOA/MVC 框架中基于 JSON 和 REST 的 RESTful 身份验证的详细信息.由于我们不仅允许通过 HTTP/1.1 进行通信，还允许通过命名管道或 GDI 消息(本地)进行通信，因此我们尝试实现真正的 RESTful 身份验证模式，而不依赖于 HTTP 特异性(如标头或 cookie).

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).

后记:在 URI 中添加签名可能被视为不好的做法(因为它会出现在 http 服务器日志中)，因此必须加以缓解，例如通过适当的 TTL 来避免重播.但是如果你的 http 日志被泄露，你肯定会遇到更大的安全问题.

Later Note: adding a signature in the URI can be seen as bad practice (since for instance it will appear in the http server logs) so it has to be mitigated, e.g. by a proper TTL to avoid replays. But if your http logs are compromised, you will certainly have bigger security problems.

在实践中，即将推出的 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 机制，而是应该从通信层中抽象出来.如果您使用 HTTP 通信，多亏了 Let's Encrypt 倡议，没有理由不使用正确的 HTTPS，这是除了任何身份验证方案外，还需要.

It's worth concluding that REST is not only HTTP-based, even if, in practice, it's also 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. And if you use HTTP communication, thanks to the Let's Encrypt initiative there is no reason not to use proper HTTPS, which is required in addition to any authentication scheme.

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