RESTful 认证

Question

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

Answer 1

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

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

基于 HTTPS 的 HTTP 基本身份验证；

Cookie 和 session 管理；

HTTP header 中的 token (例如 OAuth 2.0 + JWT)；

使用附加签名参数查询身份验证。

您必须适应，甚至更好地混合这些技术，以最好地匹配您的软件架构。

每个身份验证方案都有自己的优点和缺点，具体取决于您的安全策略和软件架构的目的。

基于 HTTPS 的 HTTP 基本身份验证

第一种解决方案基于标准 HTTPS 协议(protocol)，被大多数 Web 服务使用。

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

它很容易实现，默认在所有浏览器上可用，但有一些已知的缺点，比如浏览器上显示的可怕的身份验证窗口，它会持续存在(这里没有类似注销的功能)，一些服务器端额外的 CPU 消耗，以及用户名和密码(通过 HTTPS)传输到服务器的事实(让密码仅保留在客户端，在键盘输入期间，并作为安全哈希存储在服务器上应该更安全) .

我们可以使用 Digest Authentication ，但它也需要 HTTPS，因为它容易受到 MiM 或 Replay 攻击，并且特定于 HTTP。

通过 Cookie 的 session

老实说，在服务器上管理的 session 并不是真正的无状态。

一种可能性是在 cookie 内容中维护所有数据。而且，按照设计，cookie 在服务器端处理(实际上，客户端甚至不会尝试解释此 cookie 数据:它只是在每个连续请求时将其交还给服务器)。但是这个 cookie 数据是应用程序状态数据，所以在一个纯粹的无状态世界中，客户端应该管理它，而不是服务器。

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

cookie 技术本身是 HTTP 链接的，所以它不是真正的 RESTful，它应该是独立于协议(protocol)的，恕我直言。它容易受到 MiM 或 Replay 攻击。

通过 token (OAuth2) 授予

另一种方法是在 HTTP header 中放置一个 token ，以便对请求进行身份验证。例如，这就是 OAuth 2.0 所做的。见 the RFC 6749 :

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

简而言之，这与 cookie 非常相似，并且存在相同的问题:不是无状态的，依赖于 HTTP 传输细节，并且受 a lot of security weaknesses 的约束——包括 MiM 和 Replay——所以只能通过 HTTPS 使用。通常， JWT 用作 token 。

查询认证

查询身份验证包括通过 URI 上的一些附加参数对每个 RESTful 请求进行签名。见 this reference article 。

它在本文中是这样定义的:

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.

这种技术可能与无状态架构更兼容，也可以通过轻 session 管理(使用内存 session 而不是数据库持久性)来实现。

例如，以下是来自上述链接的通用 URI 示例:

GET /object?apiKey=Qwerty2010

应该这样传输:

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

被签名的字符串是 /object?apikey=Qwerty2010&timestamp=1261496500，签名是该字符串的 SHA256 哈希，使用 API key 的私有(private)组件。

服务器端数据缓存始终可用。例如，在我们的框架中，我们在 SQL 级别而不是 URI 级别缓存响应。所以添加这个额外的参数不会破坏缓存机制。

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

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

在实践中，即将推出的 MAC Tokens Authentication for OAuth 2.0 可能是对当前“代币授予”方案的巨大改进。但这仍然是一项正在进行的工作，并且与 HTTP 传输相关。

结论

值得得出的结论是 REST 不仅基于 HTTP，即使在实践中，它也主要通过 HTTP 实现。 REST 可以使用其他通信层。所以 RESTful 身份验证不仅仅是 HTTP 身份验证的同义词，无论谷歌如何回答。它甚至根本不应该使用 HTTP 机制，而是应该从通信层中抽象出来。如果您使用 HTTP 通信，多亏了 Let's Encrypt initiative，没有理由不使用正确的 HTTPS，除了任何身份验证方案外，HTTPS 也是必需的。