JWT 和 OAuth 身份验证之间的主要区别是什么？
我有一个使用 JWT 的无状态身份验证模型的新 SPA。我经常被要求将 OAuth 用于身份验证流程，例如要求我为每个请求发送“承载令牌”而不是简单的令牌标头，但我确实认为 OAuth 比简单的基于 JWT 的身份验证复杂得多。主要区别是什么，我应该使 JWT 身份验证的行为类似于 OAuth 吗？
我还使用 JWT 作为我的 XSRF-TOKEN 来防止 XSRF，但我被要求将它们分开？我应该把它们分开吗？此处的任何帮助将不胜感激，并可能为社区提供一套指导方针。
TL;DR 如果您有非常简单的场景，例如单个客户端应用程序、单个 API，那么使用 OAuth 2.0 可能没有回报，另一方面，许多不同的客户端（基于浏览器、本机移动、服务器端等）然后坚持 OAuth 2.0 规则可能比尝试推出自己的系统更易于管理。
如另一个答案所述，JWT（Learn JSON Web Tokens）只是一种令牌格式，它定义了一种紧凑且自包含的机制，用于在各方之间以一种可以验证和信任的方式传输数据，因为它是数字签名的。此外，JWT 的编码规则还使这些令牌在 HTTP 上下文中非常易于使用。
作为独立的（实际的令牌包含有关给定主题的信息），它们也是实现无状态身份验证机制的不错选择（又名看妈妈，没有会话！）。当走这条路时，一方必须出示才能被授予访问受保护资源的唯一权限是令牌本身，所讨论的令牌可以称为不记名令牌。
在实践中，您正在做的事情已经可以被归类为基于不记名令牌。但是，请注意您没有使用 OAuth 2.0 相关规范指定的不记名令牌（请参阅 RFC 6750）。这意味着，依赖于 Authorization HTTP 标头并使用 Bearer 身份验证方案。
关于在不知道确切细节的情况下使用 JWT 来防止 CSRF，很难确定这种做法的有效性，但老实说，这似乎并不正确和/或不值得。以下文章 (Cookies vs Tokens: The Definitive Guide) 可能是有关此主题的有用阅读资料，尤其是 XSS 和 XSRF 保护 部分。
最后一条建议，即使您不需要完整的 OAuth 2.0，我强烈建议您在 Authorization 标头中传递您的访问令牌，而不是使用自定义标头。如果它们确实是不记名令牌，请遵循 RFC 6750 的规则。如果不是，您始终可以创建自定义身份验证方案并仍然使用该标头。
授权标头由 HTTP 代理和服务器识别和特殊处理。因此，使用此类标头将访问令牌发送到资源服务器通常会降低经过身份验证的请求的泄漏或意外存储的可能性，尤其是授权标头。
OAuth 2.0 定义了一个协议，即指定令牌如何传输，JWT 定义令牌格式。
OAuth 2.0 和“JWT 身份验证”在客户端向资源服务器提供令牌的（第二）阶段具有相似的外观：令牌在标头中传递。
但是“JWT 身份验证”不是标准，也没有具体说明 Client 首先如何获取令牌（第一阶段）。这就是 OAuth 感知复杂性的来源：它还定义了客户端可以从称为授权服务器的东西获取访问令牌的各种方式。
所以真正的区别在于 JWT 只是一种令牌格式，OAuth 2.0 是一种协议（可能使用 JWT 作为令牌格式）。
首先，我们必须区分 JWT 和 OAuth。基本上，JWT 是一种令牌格式。 OAuth 是一种可以使用 JWT 作为令牌的授权协议。 OAuth 使用服务器端和客户端存储。如果您想进行真正的注销，您必须使用 OAuth2。使用 JWT 令牌进行身份验证实际上无法注销。因为您没有跟踪令牌的身份验证服务器。如果您想向 3rd 方客户端提供 API，则还必须使用 OAuth2。 OAuth2 非常灵活。 JWT 的实现非常简单，不需要很长时间即可实现。如果您的应用程序需要这种灵活性，您应该使用 OAuth2。但是，如果您不需要这个用例场景，那么实施 OAuth2 就是浪费时间。
XSRF 令牌始终在每个响应标头中发送到客户端。 CSRF 令牌是否在 JWT 令牌中发送并不重要，因为 CSRF 令牌本身是安全的。因此在 JWT 中发送 CSRF 令牌是不必要的。
JWT（JSON Web Tokens）——它只是一种令牌格式。 JWT 令牌是 JSON 编码的数据结构，包含有关发行者、主题（声明）、到期时间等信息。它经过签名以防篡改和真实性，并且可以使用对称或非对称方法加密以保护令牌信息。 JWT 比 SAML 1.1/2.0 更简单，所有设备都支持它，它比 SWT（Simple Web Token）更强大。
OAuth2 - OAuth2 解决了用户希望使用客户端软件（如基于浏览的 Web 应用程序、本机移动应用程序或桌面应用程序）访问数据的问题。 OAuth2 仅用于授权，可以授权客户端软件使用访问令牌代表最终用户访问资源。
OpenID Connect - OpenID Connect 建立在 OAuth2 之上并添加身份验证。 OpenID Connect 为 OAuth2 添加了一些约束，例如 UserInfo Endpoint、ID Token、OpenID Connect 提供者的发现和动态注册以及会话管理。 JWT 是令牌的强制格式。
CSRF 保护 - 如果您不在浏览器的 cookie 中存储令牌，则不需要实施 CSRF 保护。
看起来在这里回答的每个人都错过了 OAUTH 的实际意义
来自维基百科
OAuth 是访问授权的开放标准，通常用作互联网用户授予网站或应用程序访问其在其他网站上的信息但不提供密码的一种方式。 [1] Google、Facebook、Microsoft 和 Twitter 等公司使用此机制来允许用户与第三方应用程序或网站共享有关其帐户的信息。
这里的关键点是access delegation。当存在基于 id/pwd 的身份验证时，为什么有人会创建 OAUTH，由像 OTP 之类的多因素身份验证支持，并且可以通过 JWT 进一步保护，这些 JWT 用于保护对路径的访问（如 OAUTH 中的范围）并设置到期使用权
如果消费者仅通过您再次托管在您的端点上的受信任网站（或应用程序）访问他们的资源（您的端点），则使用 OAUTH 毫无意义
只有在资源所有者（用户）想要通过第三方客户端（外部应用程序）访问他们（您的）资源（端点）的情况下，如果您是 OAUTH provider，您可以进行 OAUTH 身份验证。 它是为相同目的而创建的，尽管您通常可以滥用它
另一个重要说明：
您可以随意使用 authentication 一词来表示 JWT 和 OAUTH，但它们都不提供身份验证机制。是的，一种是令牌机制，另一种是协议，但一旦通过身份验证，它们仅用于授权（访问管理）。您必须使用 OPENID 类型身份验证或您自己的客户端凭据来支持 OAUTH
找出 JWT 和 OAuth 之间的主要区别
OAuth 2.0 定义了一种协议，而 JWT 定义了一种令牌格式。 OAuth 可以使用 JWT 作为令牌格式或作为不记名令牌的访问令牌。 OpenID 连接主要使用 JWT 作为令牌格式。
JWT 是一种开放标准，它定义了一种紧凑且自包含的方式，用于在各方之间安全地传输信息。它是一种身份验证协议，我们允许在两方（客户端和服务器）之间传输编码的声明（令牌），并在识别客户端后发布令牌。对于每个后续请求，我们都会发送令牌。
而 OAuth2 是一个授权框架，它具有由框架定义的一般程序和设置。 JWT 可以用作 OAuth2 内部的一种机制。
您可以在此处阅读更多信息
OAuth or JWT? Which one to use and why?
Jwt 是一套严格的指令，用于签发和验证已签名的访问令牌。令牌包含应用程序用来限制对用户的访问的声明
另一方面，OAuth2 不是协议，它是一个委托授权框架。考虑非常详细的指南，让用户和应用程序在私人和公共环境中授权其他应用程序的特定权限。位于 OAUTH2 之上的 OpenID Connect 为您提供身份验证和授权。它详细说明了多个不同的角色、系统中的用户、API 等服务器端应用程序以及网站或本机移动应用程序等客户端如何相互进行身份验证
注意 oauth2 可以与 jwt 一起使用，实现灵活，可扩展至不同应用
JWT 令牌最多需要在运行时资源服务器和授权服务器之间的一次性通信。资源服务器需要向授权服务器请求公钥来解密 JWT 令牌。这可以在资源服务器启动时完成。这甚至可以存储在资源服务器中的属性文件中，完全避免查询。
OAuth2 解决了用户希望使用基于浏览器的 Web 应用程序、本机移动应用程序或桌面应用程序等客户端软件访问数据的问题。 OAuth2 仅用于授权，可以授权客户端软件使用访问令牌代表最终用户访问资源。
OAuth2 可以与 JWT 令牌或作为不记名令牌的访问令牌一起使用。
