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

Question

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

Answer 1

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

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

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

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

如果仍有任何不清楚的地方，请编辑您的问题以澄清您不是 100% 清楚什么，我相信我们可以进一步帮助您。

Answer 2

来自Auth0.com

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

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

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

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

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

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

• 移动就绪：当您开始在本机平台（iOS、Android、Windows 8 等）上工作时，使用基于令牌的方法时，cookie 并不理想，这大大简化了这一点。

• CSRF：由于您不依赖 cookie，因此您不需要防止跨站点请求（例如，不可能 sib 您的站点，生成 POST 请求并重新使用现有的身份验证 cookie，因为将没有）。

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

Answer 3

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

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

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

Answer 4

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

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

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

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

来源（ 网络档案）

Answer 5

基于令牌（安全/认证）

这意味着为了证明我们可以访问，我们首先必须接收令牌。 在现实生活中，令牌可能是建筑物的门禁卡，也可能是打开房屋锁的钥匙。 为了让您取回办公室的钥匙卡或家的钥匙，您首先需要证明您是谁，并且您确实可以访问该令牌。 它可以像向某人展示您的 ID 或给他们一个秘密密码一样简单。 所以想象一下我需要进入我的办公室。 我下到安全办公室，给他们看我的身份证，他们给了我这个令牌，让我进入大楼。 现在，只要我随身携带令牌，我就可以不受限制地在建筑物内做任何我想做的事情。

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

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

想象一下，每次我们进入办公室的一扇门时，我们都必须向坐在门旁边的每个人提供密码。 现在这将非常糟糕，因为这意味着我们办公室内的任何人都可以获取我们的密码并冒充我们，这非常糟糕。 相反，我们所做的是检索令牌，当然还有密码，但我们从一个人那里检索。 然后我们可以在建筑物内的任何地方使用这个令牌。 当然，如果我们丢失了令牌，我们会遇到与其他人知道我们的密码一样的问题，但这导致我们如何确保如果我们丢失了令牌，我们可以撤销访问权限，也许token 的存活时间不能超过 24 小时，所以第二天我们来办公室时，我们需要再次出示我们的 ID。 但是，我们仍然只向一个人出示 ID，那就是坐在我们取回令牌的地方的保安。

Answer 6

问题很老，技术已经进步，这是目前的状态：

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

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

Answer 7

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

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

更新：目前，我们有更先进的基于令牌的技术，称为JWT（Json Web 令牌） 。 这项技术有助于在多个系统中使用相同的令牌，我们称之为单点登录。

基本上基于 JSON 的令牌包含有关用户详细信息和令牌到期详细信息的信息。 因此，如果令牌无效或基于详细信息过期，该信息可用于进一步验证或拒绝请求。

Answer 8

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

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

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

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

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

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

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

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

Answer 9

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