基于 OAuth 和基于 Token 的身份验证有什么区别？

这是一个很好的问题——关于令牌和 OAuth 存在很多混淆。

首先，当您提到 OAuth 时，您可能指的是 OAuth2 standard。这是 OAuth 协议的最新版本，也是大多数人在说“OAuth”时专门谈论的内容。

OAuth 协议支持几种不同类型的身份验证和授权（准确地说是 4 种）。

其次，OAuth 协议通过令牌对用户进行身份验证来工作。这里的想法是这样的：

而不是让您的用户在每个请求中都将他们的实际凭据发送到您的服务器（就像他们使用基本身份验证一样，用户针对每个请求将他们的用户名/密码发送到服务器），使用 OAuth，您首先将您的用户凭据交换为'token'，然后根据这个'token'对用户进行身份验证。

OAuth 的想法是，通过要求用户不那么频繁地通过网络传递他们的机密凭证，可以减少坏事的发生。 （无论如何，这就是这个想法。）

现在，这就是令牌发挥作用的地方：OAuth 规范是围绕令牌的概念构建的，但没有具体说明什么是令牌。

在最“一般”的意义上，令牌只是一个唯一标识用户的字符串。而已。

人们意识到了这一点，并开发了一种用于创建令牌的新标准，称为 JSON Web Token standard。该标准基本上提供了一组规则，用于以非常特定的方式创建令牌，这使得令牌对您更有用。

JWT 允许您执行以下操作：

对令牌进行加密签名，以便您知道令牌没有被用户篡改。

加密令牌，使内容无法以纯文本形式读取。

以标准方式将 JSON 数据嵌入到令牌字符串中。

现在，在大多数情况下：开发社区中的几乎每个人都同意，如果您使用任何类型的 OAuth，那么您使用的令牌应该是 JSON Web 令牌。

好的！现在我们已经介绍了背景故事，让我回答你的问题。

您在上面所做的选择是您是否要启用完整的 OAuth2 认证/授权规范（这非常复杂），或者您是否只是想要一些基本的“令牌认证”。

因为 OAuth 协议提供了多种不同的方式来以符合标准的方式进行身份验证，所以它给大多数身份验证系统增加了很多复杂性。

正因为如此，许多框架都提供了 OAuth2 密码授予流程的“简化”版本，这本质上是一种简单的方法，其中：

用户通过 /login 等 URL 将他们的用户名/密码发送到您的服务器。

您的服务器为用户生成 JWT 令牌。

您的服务器将该令牌返回给用户。

用户将此令牌存储在他们的 cookie、移动设备或可能的 API 服务器中，并在其中使用它来发出请求。

再说一遍：上面的流程不符合 OAuth，但它是一个稍微简单的版本，仍然使用令牌。

这里的要点是令牌 (JWT) 通常很有用，并且不需要与 OAuth 流配对。

我意识到这是一堵文字墙，但希望它能更深入地回答您的问题=）

---

OAuth 是授权而非身份验证的规范

OAuth 2.0 是授权规范，但不是身份验证规范。 RFC 6749，3.1. Authorization Endpoint 明确表示如下：

授权端点用于与资源所有者交互并获得授权。授权服务器必须首先验证资源所有者的身份。授权服务器验证资源所有者的方式（例如，用户名和密码登录、会话 cookie）超出了本规范的范围。

如果您想向您的 api 授予对第三方服务的访问权限，请仅使用 OAuth。即使您使用 OAuth，您也需要某种身份验证（基于令牌或基于会话等）来验证使用。 OAuth 不是为身份验证而设计的。

请参阅此question。

---

当您从受保护的 Web 服务请求资源时，您可以在调用时提供身份验证令牌。令牌充当访问资源的“密码”。

OAuth 只是特定类型的基于令牌的身份验证方法。

---