api - 在不使用HTTP session 的情况下将身份验证 token 存储在RESTful API中

Question

我正在构建具有多个服务器的RESTful API，我想知道是否可以将访问 token 存储在中央数据库服务器中，然后针对每个请求，通过查询数据库并执行操作来验证此访问 token 是否有效给定的。

如果我为此工作使用 session ，它将变成非RESTful吗？即使我将 session 数据存储在数据库中也一样吗？长期以来，这对我来说是一个令人困惑的想法。

Answer 1

REST是无状态的

REST代表代表性状态转移，此体系结构由Roy Thomas Fielding在chapter 5 of his dissertation中定义。

Fielding为REST体系结构定义了一组约束。这些约束之一是客户端与服务器之间的stateless通信，定义如下(突出显示的内容不在他的论文中):

5.1.3 Stateless

[...] each request from client to server must contain all of the information necessary to understand the request, and cannot take advantage of any stored context on the server. Session state is therefore kept entirely on the client. [...]

因此，如果将 session 状态保留在服务器上，则会破坏 stateless constraint。因此，它不是REST。在REST中，服务器上没有 session ，因此，您没有 session 标识符。

每个请求必须包含所有要处理的数据

从客户端到服务器的每个请求都必须包含服务器要理解的所有必要信息。使用它，您将不依赖于存储在服务器上的任何 session 上下文。

例如，在访问需要身份验证的 protected 资源时，每个请求必须包含所有需要正确身份验证/授权的数据。这意味着将对每个请求执行身份验证。

看看 RFC 7235中有关新身份验证方案的注意事项的报价:

5.1.2. Considerations for New Authentication Schemes

There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can work:

• HTTP authentication is presumed to be stateless: all of the information necessary to authenticate a request MUST be provided in the request, rather than be dependent on the server remembering prior requests. [...]

身份验证数据(凭证)应属于标准HTTP Authorization header 。从 RFC 7235:

4.2. Authorization

The Authorization header field allows a user agent to authenticate itself with an origin server -- usually, but not necessarily, after receiving a 401 (Unauthorized) response. Its value consists of credentials containing the authentication information of the user agent for the realm of the resource being requested.

Authorization = credentials

[...]

请注意，此HTTP header 的名称很不幸，因为它带有身份验证数据而不是授权数据。无论如何，这是用于发送凭据的标准 header 。

基于 token 的身份验证

在执行基于 token 的身份验证时， token 是您的凭据。在这种方法中，您的硬凭证(用户名和密码)被交换为在每个请求中发送的 token 。同样，必须对每个请求都执行身份验证，因此您将不会利用服务器上存储的任何上下文。

将 token 存储在服务器中的某处非常有效。而且它不会破坏REST体系结构的 stateless constraint。

代币

基本上， token 可以是不透明的(除了值本身，不显示任何细节，例如随机字符串)，也可以是独立的(例如JSON Web token ):

随机字符串:可以通过生成随机字符串并将其具有到期日期和与之关联的用户标识符持久保存到数据库中来发行 token 。

JSON Web token (JWT):由RFC 7519定义，这是一种用于在双方之间安全地表示声明的标准方法。 JWT是一个自包含的 token ，使您可以在有效负载中存储用户标识符，有效期和任何您想要的内容(但不存储密码)，该有效负载是JSON编码为Base64。客户端可以读取有效负载，并且可以通过在服务器上验证其签名轻松地检查 token 的完整性。如果您不需要跟踪JWT token ，则无需持久化它们。虽然如此，通过持久保留 token ，您将有可能使 token 无效并撤销它们的访问。要查找与JWT一起使用的大量资源，请查看http://jwt.io。

您可以在 many databases上保留 token 。根据您的要求，您可以探索不同的解决方案，例如 relational databases， key-value stores或 document stores。