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

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

• 基于 HTTPS 的 HTTP 基本身份验证；
• Cookie 和会话管理；
• HTTP 标头中的令牌（例如 OAuth 2.0 + JWT）；
• 使用附加签名参数查询身份验证。

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

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

基于 HTTPS 的 HTTP 基本身份验证

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

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

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

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

通过 Cookie 进行会话

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

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

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

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

通过令牌 (OAuth2) 授予

另一种方法是在 HTTP 标头中放置一个令牌，以便对请求进行身份验证。例如，这就是 OAuth 2.0 所做的。请参阅RFC
6749：

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

简而言之，这与 cookie 非常相似，并且存在相同的问题：不是无状态的，依赖于 HTTP
传输细节，并且存在许多安全漏洞——包括 MiM 和
Replay——因此只能通过 HTTPS 使用。通常，JWT用作令牌。

查询认证

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

在这篇文章中是这样定义的：

所有 REST 查询都必须通过使用私有凭证作为签名令牌以小写字母顺序对查询参数进行签名来进行身份验证。签名应该发生在 URL 编码查询字符串之前。

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

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

GET /object?apiKey=Qwerty2010

应该这样传送：

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

被签名的字符串是/object?apikey=Qwerty2010&timestamp=1261496500并且签名是使用 API
密钥的私有组件的该字符串的 SHA256 哈希。

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

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

稍后注意 ：在 URI 中添加签名可能被视为不好的做法（例如，它将出现在 http 服务器日志中），因此必须减轻它，例如通过适当的 TTL
以避免重播。但是如果你的http日志被泄露，你肯定会遇到更大的安全问题。

在实践中，即将推出的 OAuth 2.0 的 MAC
令牌身份验证可能是对“由令牌授予”当前方案的巨大改进。但这仍然是一项正在进行的工作，并且与 HTTP 传输相关联。

结论

值得得出的结论是 REST 不仅基于 HTTP，即使在实践中，它也主要通过 HTTP 实现。REST 可以使用其他通信层。因此，无论 Google
回答什么，RESTful 身份验证都不仅仅是 HTTP 身份验证的同义词。它甚至根本不应该使用 HTTP 机制，而是应该从通信层抽象出来。如果您使用
HTTP 通信，由于Let’s Encrypt 倡议，没有理由不使用正确的
HTTPS，这是任何身份验证方案之外的必要条件。