在不使用HTTP会话的情况下将身份验证令牌存储在RESTful API中 [英] Storing authentication tokens in a RESTful API without using HTTP sessions
问题描述
我正在构建具有多个服务器的RESTful API，我想知道是否可以将访问令牌存储在中央数据库服务器中，然后针对每个请求，通过查询数据库来验证此访问令牌是否有效，然后执行给定的动作.
I am building a RESTful API with multiple servers and I want to know if it's okay to store the access token in a central database server and then, for every request, verify if this access token is valid by querying the database and then performing the action given.
如果我为此工作使用会话，它将变成非RESTful吗?即使我将会话数据存储在数据库中也一样吗?很久以来这对我来说都是一个令人困惑的主意.
If I use sessions for this job, will it become non RESTful? Like even if I store the session data in a database? It's been a confusing idea to me for so long.
推荐答案
REST是无状态的
REST代表代表性状态转移，此体系结构由Roy Thomas Fielding在
REST is stateless
REST stands for Representational State Transfer and this architecture was defined by Roy Thomas Fielding in the chapter 5 of his dissertation.
Fielding为REST体系结构定义了一组约束.这些限制之一是客户端之间的无状态通信和服务器，定义如下(重点内容不在他的论文中):
Fielding defined a set of constraints for the REST architecture. One of these constraints is the stateless communication between client and server, defined as following (the highlights are not present in his dissertation):
[...]从客户端到服务器的每个请求必须包含理解该请求所需的所有信息，并且不能利用服务器上任何已存储的上下文. 因此，会话状态完全保留在客户端上. [...]
[...] 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. [...]
So, if you keep the session state on the server, you break the stateless constraint. Hence, it's not REST. In REST you won't have a session on the server and, consequently, you won't have session identifiers.
从客户端到服务器的每个请求必须包含服务器必须理解的所有必要信息.有了它，您将不依赖于存储在服务器上的任何会话上下文.
Each request from client to server must contain all of the necessary information to be understood by the server. With it, you are not depending on any session context stored on the server.
例如，当访问需要身份验证的受保护资源时，每个请求都必须包含所有必须经过正确身份验证/授权的必要数据.这意味着将对每个请求执行身份验证.
When accessing protected resources that require authentication, for example, each request must contain all necessary data to be properly authenticated/authorized. It means the authentication will be performed for each request.
请参见 RFC 7235 中的引号对于新的身份验证方案:
Have a look at this quote from the RFC 7235 regarding considerations for new authentication schemes:
HTTP身份验证框架的某些方面 对新的身份验证方案如何工作设置了限制:
There are certain aspects of the HTTP Authentication Framework that put constraints on how new authentication schemes can work:
- 假定HTTP身份验证是无状态的:所有 必须提供验证请求所需的信息 在请求中，而不是依赖于服务器的记忆 事先要求. [...]
- 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 标头.来自 RFC 7235 :
And authentication data (credentials) should belong to the standard HTTP Authorization header. From the RFC 7235:
Authorization标头字段允许用户代理进行身份验证
本身与原始服务器一起使用-通常(但不一定)在
收到401(未经授权)响应.其值包括
包含用户身份验证信息的凭据
所请求资源领域的代理.
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标头的名称很不幸，因为它包含 authentication 数据而不是 authorization .无论如何，这是用于发送凭据的标准标头.
Please note that the name of this HTTP header is unfortunate because it carries authentication data instead of authorization. Anyways, this is the standard header for sending credentials.
执行基于令牌的身份验证时，令牌是您的凭据.用这种方法，您的硬凭证(用户名和密码)将交换为在每个请求中发送的令牌.同样，必须为每个请求执行身份验证，因此您将不会利用服务器上存储的任何上下文.
When performing a token based authentication, the tokens are your credentials. In this approach, your hard credentials (username and password) are exchanged for a token that is sent in each request. Again, the authentication must be performed for every request, so you won't take advantage of any stored context on the server.
将令牌存储在服务器中的某处非常有效.并且不会破坏无状态约束 REST体系结构.
It's perfectly valid storing your tokens somewhere in your server. And it won't break the stateless constraint of the REST architecture.
基本上，令牌可以是不透明(除了值本身，它不显示任何细节，例如随机字符串)，或者可以是自包含的(例如 JSON Web令牌):
Basically, the tokens can be opaque (which reveals no details other than the value itself, like a random string) or can be self-contained (like JSON Web Token):
-
随机字符串:可以通过生成随机字符串并将其具有到期日期和与之关联的用户标识符持久存储到数据库中来发行令牌.
Random String: A token can be issued by generating a random string and persisting it to a database with an expiration date and with a user identifier associated to it.
JSON Web令牌(JWT):由 RFC 7519定义，这是一种在两方之间安全地表示索赔的标准方法. JWT是一个自包含的令牌，可让您在有效负载中存储用户标识符，有效期以及您想要的任何内容(但不存储密码)，该内容为 http://jwt.io .
JSON Web Token (JWT): Defined by the RFC 7519, it's a standard method for representing claims securely between two parties. JWT is a self-contained token and enables you to store a user identifier, an expiration date and whatever you want (but don't store passwords) in a payload, which is a JSON encoded as Base64. The payload can be read by the client and the integrity of the token can be easily checked by verifying its signature on the server. You won't need to persist JWT tokens if you don't need to track them. Althought, by persisting the tokens, you will have the possibility of invalidating and revoking the access of them. To find some great resources to work with JWT, have a look at http://jwt.io.
有许多数据库，您可以在其中保留令牌.根据您的要求，您可以探索不同的解决方案，例如关系数据库，键值存储或
There are many databases where you can persist your tokens. Depending on your requirements, you can explore different solutions such as relational databases, key-value stores or document stores.
这篇关于在不使用HTTP会话的情况下将身份验证令牌存储在RESTful API中的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
