我想了解基于令牌的认证意味着什么。我在网上搜索，但找不到任何可以理解的东西。

我认为这里解释得很好——只引用长篇文章的关键句子：

The general concept behind a
token-based authentication system is
simple. Allow users to enter their
username and password in order to
obtain a token which allows them to
fetch a specific resource - without
using their username and password.
Once their token has been obtained,
the user can offer the token - which
offers access to a specific resource
for a time period - to the remote
site.

号

换句话说：添加一级间接身份验证——用户不必使用每个受保护资源的用户名和密码进行身份验证，而是通过这种方式进行一次身份验证(在有限持续时间的会话内)，获得一个时间限制的令牌作为返回，并在会话期间使用该令牌进行进一步的身份验证。

优点很多——例如，一旦用户获得了令牌，就可以将它传递给他们愿意在有限的时间和有限的一组资源内信任的其他自动化系统，但不愿意信任他们的用户名和密码(即，对于允许他们访问的每一个资源，至少是永久性的或非永久性的)。直到他们更改密码)。

如果还有什么不清楚的地方，请编辑你的问题，澄清你不完全清楚的地方，我相信我们会进一步帮助你。

来自auth0.com

Token-Based Authentication, relies on a signed token that is sent to
the server on each request.

What are the benefits of using a token-based approach?

• Cross-domain / CORS: cookies + CORS don't play well across different domains. A token-based approach allows you to make AJAX
  calls to any server, on any domain because you use an HTTP header
  to transmit the user information.

• Stateless (a.k.a. Server side scalability): there is no need to keep a session store, the token is a self-contained entity that conveys all the user information. The rest of the state lives in cookies or local storage on the client side.

• CDN: you can serve all the assets of your app from a CDN (e.g. javascript, HTML, images, etc.), and your server side is just the API.

• Decoupling: you are not tied to any particular authentication scheme. The token might be generated anywhere, hence your API can
  be called from anywhere with a single way of authenticating those
  calls.

• Mobile ready: when you start working on a native platform (iOS, Android, Windows 8, etc.) cookies are not ideal when consuming a
  token-based approach simplifies this a lot.

• CSRF: since you are not relying on cookies, you don't need to protect against cross site requests (e.g. it would not be possible to
  sib your site, generate a POST request and re-use the existing authentication cookie because there will be none).

• Performance: we are not presenting any hard perf benchmarks here, but a network roundtrip (e.g. finding a session on database)
  is likely to take more time than calculating an HMACSHA256 to
  validate a token and parsing its contents.

号

token是一段只有Server X可能创建的数据，其中包含足够的数据来标识特定用户。

您可以提供登录信息并要求Server X提供token；然后您可以提供token并要求Server X执行一些特定于用户的操作。

tokens是使用密码学领域各种技术的各种组合以及更广泛的安全研究领域的输入创建的。如果你决定去创建你自己的token系统，你最好是非常聪明。

令牌是由服务器创建的一段数据，包含用于标识特定用户和令牌有效性的信息。令牌将包含用户的信息，以及一个特殊的令牌代码，用户可以通过每个支持身份验证的方法传递给服务器，而不是直接传递用户名和密码。

基于令牌的身份验证是一种安全技术，它使用服务器提供的安全令牌对试图登录到服务器、网络或其他安全系统的用户进行身份验证。

如果用户可以通过传递安全令牌向服务器证明自己是有效用户，则身份验证成功。服务验证安全令牌并处理用户请求。

在令牌被服务验证之后，它被用来为客户机建立安全上下文，这样服务就可以为连续的用户请求做出授权决策或审计活动。

访问来源

基于令牌(安全/身份验证)

这意味着为了证明我们有权访问，我们必须先接收令牌。在现实生活中，代币可以是建筑物的门禁卡，也可以是锁门的钥匙。为了让你取回一张办公室的钥匙卡或者你家的钥匙，你首先需要证明你是谁，事实上你确实有权使用这张令牌。它可以是一些简单的东西，比如给某人显示你的ID或者给他们一个密码。想象一下我需要进入我的办公室。我去了安全办公室，我给他们看了我的身份证，他们给了我这个令牌，让我进入大楼。现在我可以不受限制地在大楼里做我想做的任何事情，只要我有我的代币。

基于令牌的安全有什么好处？

如果我们回想一下不安全的API，在这种情况下我们必须为我们想要做的每件事提供密码。

想象一下，每次我们走进办公室的门，我们都必须给坐在门旁边的每个人我们的密码。那就太糟糕了，因为这意味着办公室里的任何人都可以拿走我们的密码，冒充我们，这就太糟糕了。相反，我们要做的是检索令牌，当然还有密码，但是我们从一个人那里检索。然后我们可以在我们想要的任何地方使用这个令牌。当然，如果我们丢失了令牌，我们会遇到与其他人知道我们的密码相同的问题，但这会导致我们陷入这样的问题：我们如何确保如果我们丢失了令牌，我们就可以撤销访问权限，并且令牌的寿命不应超过24小时，所以第二天我们来到办公室时，我们需要再次显示我们的ID。不过，我们只向一个人展示身份证，那是我们取回代币的保安。

问题由来已久，技术先进，现阶段情况如下：

JSONWeb令牌(JWT)是一种基于JSON的开放标准(RFC7519)，用于在Web应用程序环境中在各方之间传递声明。令牌被设计成紧凑的、URL安全的和可用的，特别是在Web浏览器单点登录(SSO)上下文中。

https://en.wikipedia.org/wiki/json_web_令牌

它只是散列，在数据库或其他方式中与用户关联。该令牌可用于验证和授权用户访问应用程序的相关内容。要在客户端上检索此令牌，需要登录。首次登录后，您需要保存检索到的令牌，而不是会话、会话ID等任何其他数据，因为这里的所有内容都是访问应用程序其他资源的令牌。

令牌用于确保用户的真实性。

当你注册一个新网站时，通常会收到一封电子邮件来激活你的帐户。这封电子邮件通常包含一个点击链接。该链接的一部分，包含一个令牌，服务器知道该令牌并可以将其与您的帐户关联。令牌通常会有一个与之相关联的到期日期，因此您可能只有一个小时的时间来单击链接并激活您的帐户。对于cookie或会话变量，这些都不可能实现，因为客户使用的未知设备或浏览器检查电子邮件。