令牌提交的身份验证失败
介绍 (Introduction)
Token based authentication is prominent everywhere on the web nowadays. With most every web company using an API, tokens are the best way to handle authentication for multiple users.
如今，基于令牌的身份验证在网络上无处不在。 对于大多数使用API的网络公司而言，令牌是处理多个用户身份验证的最佳方法。
There are some very important factors when choosing token based authentication for your application. The main reasons for tokens are:
为应用程序选择基于令牌的身份验证时，有一些非常重要的因素。 令牌的主要原因是：
谁使用基于令牌的身份验证？ (Who Uses Token Based Authentication?)
Any major API or web application that you've come across has most likely used tokens. Applications like Facebook, Twitter, Google+, GitHub, and so many more use tokens.
您遇到的任何主要API或Web应用程序都最有可能使用了令牌。 Facebook，Twitter，Google +，GitHub等应用程序都使用令牌。
Let's take a look at exactly how it works.
让我们来看看它是如何工作的。
代币为何出现 (Why Tokens Came Around)
Before we can see how token based authentication works and its benefits, we have to look at the way authentication has been done in the past.
在我们了解基于令牌的身份验证的工作原理及其好处之前，我们必须了解一下过去身份验证的完成方式。
基于服务器的身份验证（传统方法） (Server Based Authentication (The Traditional Method))
Since the HTTP protocol is stateless, this means that if we authenticate a user with a username and password, then on the next request, our application won't know who we are. We would have to authenticate again.
由于HTTP协议是无状态的 ，这意味着如果我们使用用户名和密码对用户进行身份验证，那么在下一个请求时，我们的应用程序将不知道我们是谁。 我们将不得不再次进行身份验证。
The traditional way of having our applications remember who we are is to store the user logged in information on the server. This can be done in a few different ways on the session, usually in memory or stored on the disk.
让我们的应用程序记住我们是谁的传统方式是将用户登录信息存储在服务器上 。 这可以在会话上以几种不同的方式完成，通常在内存中或存储在磁盘上。
Here is a graph of how a server based authentication workflow would look:
这是基于服务器的身份验证工作流的外观图：
As the web, applications, and the rise of the mobile application have come about, this method of authentication has shown problems, especially in scalability.
随着网络，应用程序以及移动应用程序的兴起，这种身份验证方法尤其在可伸缩性方面出现了问题。
基于服务器的身份验证的问题 (The Problems with Server Based Authentication)
A few major problems arose with this method of authentication.
这种身份验证方法引起了一些主要问题。
Sessions: Every time a user is authenticated, the server will need to create a record somewhere on our server. This is usually done in memory and when there are many users authenticating, the overhead on your server increases.
会话 ：每次对用户进行身份验证时，服务器都需要在我们服务器上的某处创建一条记录。 这通常在内存中完成，并且当有许多用户进行身份验证时，服务器上的开销会增加。
Scalability: Since sessions are stored in memory, this provides problems with scalability. As our cloud providers start replicating servers to handle application load, having vital information in session memory will limit our ability to scale.
可伸缩性 ：由于会话存储在内存中，因此存在可伸缩性问题。 随着我们的云提供商开始复制服务器来处理应用程序负载，会话内存中的重要信息将限制我们的扩展能力。
CORS: As we want to expand our application to let our data be used across multiple mobile devices, we have to worry about cross-origin resource sharing (CORS). When using AJAX calls to grab resources from another domain (mobile to our API server), we could run into problems with forbidden requests.
CORS ：由于我们要扩展应用程序以使我们的数据可在多个移动设备上使用，因此我们不得不担心跨域资源共享（CORS）。 当使用AJAX调用从另一个域（移动到我们的API服务器）获取资源时，我们可能会遇到禁止请求的问题。
CSRF: We will also have protection against cross-site request forgery (CSRF). Users are susceptible to CSRF attacks since they can already be authenticated with say a banking site and this could be taken advantage of when visiting other sites.
CSRF ：我们还将提供针对跨站点请求伪造 （CSRF）的保护。 用户很容易受到CSRF攻击，因为他们已经可以通过银行站点进行身份验证，并且可以在访问其他站点时加以利用。
With these problems, scalability being the main one, it made sense to try a different approach.
面对这些问题，可伸缩性是主要问题，因此尝试另一种方法是有意义的。
基于令牌的工作方式 (How Token Based Works)
Token based authentication is stateless. We are not storing any information about our user on the server or in a session.
基于令牌的身份验证是无状态的 。 我们不会在服务器或会话中存储有关用户的任何信息。
This concept alone takes care of many of the problems with having to store information on the server.
仅此概念就解决了许多必须将信息存储在服务器上的问题。
No session information means your application can scale and add more machines as necessary without worrying about where a user is logged in.
没有会话信息意味着您的应用程序可以根据需要扩展和添加更多计算机，而不必担心用户登录的位置。
Although this implementation can vary, the gist of it is as follows:
尽管此实现可能有所不同，但其要点如下：
- User Requests Access with Username / Password 用户使用用户名/密码请求访问
- Application validates credentials 应用程序验证凭证
- Application provides a signed token to the client 应用程序向客户端提供签名令牌
- Client stores that token and sends it along with every request 客户端存储该令牌并将其与每个请求一起发送
- Server verifies token and responds with data 服务器验证令牌并响应数据
Every single request will require the token. This token should be sent in the HTTP header so that we keep with the idea of stateless HTTP requests. We will also need to set our server to accept requests from all domains using Access-Control-Allow-Origin: *. What's interesting about designating * in the ACAO header is that it does not allow requests to supply credentials like HTTP authentication, client-side SSL certificates, or cookies.
每个请求都将需要令牌 。 该令牌应在HTTP标头中发送，以便我们遵循无状态HTTP请求的想法。 我们还需要使用Access-Control-Allow-Origin: *将服务器设置为接受来自所有域的请求。 在ACAO标头中指定*的有趣之处在于，它不允许请求提供HTTP身份验证，客户端SSL证书或cookie之类的凭据。
Here's an infographic to explain the process:
以下是说明流程的信息图：
Once we have authenticated with our information and we have our token, we are able to do many things with this token.
一旦我们对我们的信息进行了身份验证并获得了令牌，我们就可以使用此令牌执行许多操作。
We could even create a permission based token and pass this along to a third-party application (say a new mobile app we want to use), and they will be able to have access to our data -- but only the information that we allowed with that specific token.
我们甚至可以创建一个基于权限的令牌，并将其传递给第三方应用程序（例如，我们要使用的新移动应用程序），这样他们就可以访问我们的数据， 但只能访问我们允许的信息带有特定的令牌 。
代币的好处 (The Benefits of Tokens)
无状态且可扩展 (Stateless and Scalable)
Tokens stored on client side. Completely stateless, and ready to be scaled. Our load balancers are able to pass a user along to any of our servers since there is no state or session information anywhere.
令牌存储在客户端。 完全无状态，随时可以扩展。 我们的负载平衡器能够将用户传递到我们的任何服务器，因为任何地方都没有状态或会话信息。
If we were to keep session information on a user that was logged in, this would require us to keep sending that user to the same server that they logged in at (called session affinity).
如果我们要保留有关已登录用户的会话信息，这将要求我们继续将该用户发送到他们登录时所在的同一服务器 （称为会话亲缘关系）。
This brings problems since, some users would be forced to the same server and this could bring about a spot of heavy traffic.
这带来了问题，因为某些用户将被迫使用同一台服务器，这可能会带来大量流量。
Not to worry though! Those problems are gone with tokens since the token itself holds the data for that user.
不过不用担心！ 令牌本身已解决了这些问题，因为令牌本身保存了该用户的数据。
安全 (Security)
The token, not a cookie, is sent on every request and since there is no cookie being sent, this helps to prevent CSRF attacks. Even if your specific implementation stores the token within a cookie on the client side, the cookie is merely a storage mechanism instead of an authentication one. There is no session based information to manipulate since we don’t have a session!
令牌（不是cookie）会在每个请求上发送，并且由于没有cookie发送，因此有助于防止CSRF攻击。 即使您的特定实现将令牌存储在客户端的cookie中，该cookie仅仅是一种存储机制，而不是一种认证机制。 由于没有会话，因此没有可操作的基于会话的信息！
The token also expires after a set amount of time, so a user will be required to login once again. This helps us stay secure. There is also the concept of token revocation that allows us to invalidate a specific token and even a group of tokens based on the same authorization grant.
令牌还会在设置的时间后过期，因此将要求用户再次登录。 这有助于我们保持安全。 还有令牌撤销的概念，它使我们可以基于相同的授权授予使特定令牌甚至一组令牌无效。
可扩展性（“ Friend of a Friend and Permissions”） (Extensibility (Friend of A Friend and Permissions))
Tokens will allow us to build applications that share permissions with another. For example, we have linked random social accounts to our major ones like Facebook or Twitter.
令牌将使我们能够构建彼此共享权限的应用程序。 例如，我们已将随机社交帐户链接到我们的主要帐户，例如Facebook或Twitter。
When we login to Twitter through a service (let's say Buffer), we are allowing Buffer to post to our Twitter stream.
当我们通过服务（例如Buffer）登录Twitter时，我们允许Buffer发布到我们的Twitter流中。
By using tokens, this is how we provide selective permissions to third-party applications. We could even build our own API and hand out special permission tokens if our users wanted to give access to their data to another application.
通过使用令牌，这就是我们向第三方应用程序提供选择性权限的方式 。 如果我们的用户希望将其数据访问权限授予另一个应用程序，我们甚至可以构建自己的API并发放特殊权限令牌。
多个平台和域 (Multiple Platforms and Domains)
We talked a bit about CORS earlier. When our application and service expands, we will need to be providing access to all sorts of devices and applications (since our app will most definitely become popular!).
我们之前谈到了CORS。 当我们的应用程序和服务扩展时，我们将需要提供对各种设备和应用程序的访问（因为我们的应用程序肯定会很受欢迎！）。
Having our API just serve data, we can also make the design choice to serve assets from a CDN. This eliminates the issues that CORS brings up after we set a quick header configuration for our application.
让我们的API只提供数据服务，我们还可以做出设计选择，以提供CDN中的资产。 这消除了在为应用程序设置快速标头配置后CORS出现的问题。
Access-Control-Allow-Origin: *Our data and resources are available to requests from any domain now as long as a user has a valid token.
现在，只要用户拥有有效的令牌，我们的数据和资源就可用于来自任何域的请求。
基于标准 (Standards Based)
When creating the token, you have a few options. We'll be diving more into this topic when we secure an API in a follow-up article, but the standard to use would be JSON Web Tokens.
创建令牌时，您有一些选择。 在后续文章中确保API的安全时，我们将进一步探讨该主题，但是要使用的标准是JSON Web令牌 。
This handy debugger and library chart shows the support for JSON Web Tokens. You can see that it has a great amount of support across a variety of languages. This means you could actually switch out your authentication mechanism if you choose to do so in the future!
此便捷的调试器和库图表显示了对JSON Web令牌的支持。 您会看到它对多种语言都提供了大量支持。 这意味着，如果您将来选择这样做，则实际上可以关闭认证机制！
结论 (Conclusion)
This was just a look at the how and why of token based authentication. As is always the case in the world of security, there is much, much, much, much (too many?) more to each topic and it varies per use case. We even dove into some topics on scalability which deserves its own conversation as well.
这只是基于令牌的身份验证的方式和原因。 与安全领域一样，每个主题还有很多很多（太多？），并且每个用例都不同。 我们甚至探讨了一些有关可伸缩性的主题，这也值得我们自己讨论。
This was a high level quick overview, so please feel free to point out anything that was missed or any questions you have on the matter.
这是一个高层次的快速概述，因此，请随时指出任何遗漏的内容或对此问题的任何疑问。
In our next article, we'll be looking at the anatomy of JSON Web Tokens. For full code examples on how to authenticate a Node API using JSON Web Tokens, check out our book MEAN Machine.
在下一篇文章中，我们将研究JSON Web令牌的剖析 。 有关如何使用JSON Web令牌对Node API进行身份验证的完整代码示例，请查看我们的书籍MEAN Machine 。
翻译自: https://scotch.io/tutorials/the-ins-and-outs-of-token-based-authentication
令牌提交的身份验证失败
扫一扫
1万+
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
