什么是基于令牌的身份验证？

我想了解基于令牌的身份验证的含义。我搜索了互联网，但找不到任何可以理解的东西。

我认为这在这里已得到很好的解释-仅引用长篇文章的关键句子：

基于令牌的身份验证系统背后的一般概念很简单。允许用户输入他们的用户名和密码，以获得一个令牌，该令牌允许他们获取特定资源-无需使用用户名和密码。一旦获得了他们的令牌，用户就可以向远程站点提供令牌（在一段时间内可以访问特定资源）。

换句话说：添加一个间接身份验证级别-无需为每个受保护的资源使用用户名和密码进行身份验证，用户只需以这种方式进行一次身份验证（在一段持续时间之内），然后获得一个限时令牌，并在会话期间使用该令牌进行进一步的身份验证。

有许多优势-例如，用户可以通过该令牌，一旦他们知道的话，就到一些其他自动系统，他们愿意在有限的时间和有限的资源的信任，但将不会愿意以他们的用户名和密码（即，他们被允许永久或至少直到他们更改密码）访问的每种资源信任。

如果仍然不清楚，请编辑您的问题以澄清您对100％不清楚的地方，我相信我们可以为您提供进一步的帮助。

来自Auth0.com

基于令牌的身份验证依赖于每个请求发送到服务器的签名令牌。

使用基于令牌的方法有什么好处？

• 跨网域/ CORS： Cookie + CORS在不同的域中不能很好地发挥作用。基于令牌的方法允许您对任何域上的任何服务器进行AJAX调用，因为您使用HTTP标头来传输用户信息。

• 无状态（又称服务器端可伸缩性）：无需保留会话存储，令牌是一个包含所有用户信息的自包含实体。状态的其余部分位于客户端的Cookie或本地存储中。

• CDN：您可以从CDN提供应用程序的所有资产（例如javascript，HTML，图像等），而服务器端只是API。

• 解耦：您不受任何特定身份验证方案的束缚。令牌可能在任何地方生成，因此可以通过一种对那些调用进行身份验证的单一方法从任何地方调用您的API。

• 面向移动设备的准备：当您开始在本机平台（iOS，Android，Windows 8等）上工作时，使用基于令牌的方法将cookie简化时，cookies并不理想。

• CSRF：由于您不依赖Cookie，因此无需防御跨站点请求（例如，将无法同化您的站点，生成POST请求并重新使用现有的身份验证cookie，因为不会）。

• 性能：我们在这里没有提供任何硬性能基准，但是与计算HMACSHA256来验证令牌并解析其内容相比，网络往返（例如，在数据库上查找会话）可能花费更多的时间。

A token是一条仅Server X可能创建的数据，其中包含足够的数据以标识特定用户。

您可能会显示您的登录信息并要求Server X输入token; 然后您可能会提出您的token要求Server X，并要求执行一些特定于用户的操作。

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

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

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

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

服务验证令牌后，将令牌用于为客户端建立安全上下文，以便服务可以为后续的用户请求做出授权决策或审核活动。

访问源

基于令牌（安全性/身份验证）

意味着为了让我们证明我们已经访问，我们首先必须接收令牌。在现实生活中，令牌可能是建筑物的出入卡，也可能是锁入房屋的钥匙。为了让您获取办公室的钥匙卡或家庭钥匙，您首先需要证明自己是谁，并且实际上您有权使用该令牌。它可以很简单，例如向某人显示您的ID或为他们提供秘密密码。因此，想象一下我需要进入我的办公室。我去了保安室，给他们看了我的身份证，他们给了我这个令牌，让我进入大楼。现在，只要我随身携带令牌，我就可以不受限制地进入建筑物内想要执行的任何操作。

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

如果我们回想起不安全的API，在这种情况下，我们要做的就是必须为想要做的所有事情提供密码。

想像每次我们进入办公室的门时，我们都必须给坐在门旁的所有人提供密码。现在那将是很糟糕的事情，因为这意味着我们办公室内的任何人都可以使用我们的密码并假冒我们，这很糟糕。取而代之的是，我们要做的是检索令牌，当然也将其与密码一起检索，但是我们是从一个人那里检索到的。然后，我们可以在建筑物内的任何地方使用此令牌。当然，如果我们丢失了令牌，我们将面临与别人知道我们的密码相同的问题，但是这会导致我们陷入困境，例如，如何确保如果丢失令牌，我们可以撤消访问权限，甚至可能撤销令牌寿命不应超过24小时，因此，第二天到办公室时，我们需要再次显示身份证。但是，仍然只有一个人向我们显示ID，

问题是老而技术先进，这是当前状态：

JSON Web令牌（JWT）是基于JSON的开放标准（RFC 7519），用于在Web应用程序环境中的各方之间传递声明。令牌被设计为紧凑，URL安全且可用的，特别是在Web浏览器单点登录（SSO）上下文中。

https://zh.wikipedia.org/wiki/JSON_Web_Token

它只是哈希，它与数据库中的用户或其他某种方式相关联。该令牌可用于认证然后授权用户访问与应用程序相关的内容。要在客户端上检索此令牌，需要登录。首次登录后，您无需保存检索到的令牌，而无需保存任何其他数据（如会话，会话ID），因为此处的所有内容都是访问应用程序其他资源的令牌。

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

如今，保护Web API资源安全的最佳方法是使用需要由客户端与每个客户端发送给服务器的签名令牌（包含足以识别特定用户的信息）对Web API服务器中的用户进行身份验证。每个请求。这称为基于令牌的身份验证方法。

基于令牌的身份验证的工作方式如下：

用户将名称和密码输入客户端（客户端表示浏览器或移动设备等）。

然后，客户端将这些凭据（即用户名和密码）发送到授权服务器。

然后，授权服务器对客户端凭据（即用户名和密码）进行身份验证，然后生成并返回访问令牌。该访问令牌包含足以标识用户的信息，还包含令牌的到期时间。

然后，客户端应用程序在HTTP请求的Authorization标头中包含访问令牌，以从资源服务器访问受限制的资源，直到令牌过期为止。

本文将逐步介绍如何在WEB API中实现基于令牌的身份验证。

https://dotnettutorials.net/lesson/token-based-authentication-web-api/

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