Answers:
TL; DR 如果您有非常简单的场景，例如单个客户端应用程序，单个API，那么使用OAuth 2.0可能不会成功，另一方面，很多不同的客户端（基于浏览器的，本机移动的，服务器端的）等等），那么坚持使用OAuth 2.0规则可能比尝试滚动自己的系统更易于管理。
如另一个答案所述，JWT（学习JSON Web令牌）只是一种令牌格式，它定义了一种紧凑且自包含的机制，可以通过验证和信任的方式在各方之间传输数据，因为它是经过数字签名的。此外，JWT的编码规则还使这些令牌在HTTP上下文中非常易于使用。
由于是独立的（实际令牌包含有关给定主题的信息），它们还是实现无状态身份验证机制（aka Look mum，no session！）的不错选择。当走这条路线时，要授予一方访问受保护资源的唯一条件就是令牌本身，有问题的令牌可以称为承载令牌。
在实践中，您所做的已经可以基于承载令牌进行分类。但是，请确保您没有使用OAuth 2.0相关规范所指定的承载令牌（请参阅RFC 6750）。这意味着依赖于AuthorizationHTTP标头并使用Bearer身份验证方案。
关于在不知道确切细节的情况下使用JWT来防止CSRF的问题，很难确定该做法的有效性，但是说实话，这似乎并不正确和/或不值得。以下文章（Cookies与令牌：权威指南）可能是关于该主题的有用读物，尤其是XSS和XSRF保护部分。
最后一条建议是，即使您不需要完整的OAuth 2.0，我也强烈建议您在Authorization标头中传递访问令牌，而不要使用自定义标头。如果它们确实是承载令牌，则遵循RFC 6750的规则，否则，您始终可以创建自定义身份验证方案，并仍然使用该标头。
HTTP代理和服务器会识别并特别处理授权标头。因此，使用这种报头向资源服务器发送访问令牌的方法通常降低了已认证请求（特别是授权报头）泄漏或意外存储的可能性。
（来源：RFC 6819，第5.4.1节）
OAuth 2.0定义了协议，即指定了令牌的传输方式，JWT定义了令牌格式。
在第2阶段，OAuth 2.0和“ JWT身份验证”具有相似的外观，其中客户端将令牌提供给资源服务器：令牌在标头中传递。
但是“ JWT身份验证”不是标准，并且没有指定客户端首先如何获得令牌（第一阶段）。这就是OAuth的复杂性来自何处：它还定义了客户端可以从称为授权服务器的某种东西获取访问令牌的各种方式。
因此，真正的区别在于JWT只是一种令牌格式，OAuth 2.0是一种协议（可以使用JWT作为令牌格式）。
首先，我们必须区分JWT和OAuth。基本上，JWT是令牌格式。OAuth是可以使用JWT作为令牌的授权协议。OAuth使用服务器端和客户端存储。如果要真正注销，则必须使用OAuth2。使用JWT令牌的身份验证实际上无法注销。因为您没有跟踪令牌的身份验证服务器。如果要向第三方客户端提供API，则还必须使用OAuth2。OAuth2非常灵活。JWT的实现非常容易，并且不需要很长时间即可实现。如果您的应用程序需要这种灵活性，则应使用OAuth2。但是，如果您不需要这种用例场景，则实现OAuth2会浪费时间。
XSRF令牌始终在每个响应标头中发送给客户端。是否以JWT令牌发送CSRF令牌并不重要，因为CSRF令牌具有自身安全性。因此，无需在JWT中发送CSRF令牌。
JWT（JSON Web令牌） -它只是令牌格式。JWT令牌是JSON编码的数据结构，包含有关发行者，主题（声明），到期时间等信息。经过签名以防篡改和真实性进行签名，并且可以使用对称或不对称方法对其进行加密以保护令牌信息。JWT比SAML 1.1 / 2.0简单，并且受所有设备支持，并且比SWT（简单Web令牌）更强大。
OAuth2 -OAuth2解决了用户希望使用客户端软件（例如基于浏览的Web应用程序，本机移动应用程序或桌面应用程序）访问数据的问题。OAuth2仅用于授权，可以授权客户端软件使用访问令牌代表最终用户访问资源。
OpenID Connect -OpenID Connect建立在OAuth2之上并添加身份验证。OpenID Connect向OAuth2添加了一些约束，例如UserInfo端点，ID令牌，OpenID Connect提供程序的发现和动态注册以及会话管理。JWT是令牌的强制格式。
CSRF保护 -如果您没有在浏览器的cookie中存储令牌，则无需实施CSRF保护。
您可以在这里阅读更多详细信息http://proficientblog.com/microservices-security/
似乎每个在这里回答的人都错过了OAUTH的争论点
来自维基百科
OAuth是访问授权的开放标准，通常用作Internet用户授予网站或应用程序访问其在其他网站上的信息的途径，而无需给他们提供密码。[1] Google，Facebook，Microsoft和Twitter等公司使用此机制来允许用户与第三方应用程序或网站共享有关其帐户的信息。
这里的重点是access delegation。当存在基于id / pwd的身份验证时，为什么有人会创建OAUTH，而该身份验证由OTP等多因素身份验证支持，并且可以由用于保护路径访问（如OAUTH中的作用域）的JWT保护，并且设置了有效期访问
如果消费者仅通过受信任的网站（或应用程序）访问您的资源（您的端点），而OAUTH没有任何用处，那么您将再次托管在您的端点上
你可以去OAuth认证只是如果你是一个OAUTH provider在资源拥有者（用户）希望通过第三方客户端（外部应用程序）来访问他们的（你的）资源（终点）的情况下。尽管您通常会滥用它，但它是完全出于相同目的而创建的
另一个重要说明：
您可以随意使用authenticationJWT和OAUTH 这个词，但都不提供身份验证机制。是的，一种是令牌机制，另一种是协议，但是一旦通过身份验证，它们仅用于授权（访问管理）。您必须使用OPENID类型身份验证或您自己的客户端凭据来支持OAUTH
找到JWT和OAuth之间的主要区别
OAuth 2.0定义了协议，而JWT定义了令牌格式。
OAuth可以使用JWT作为令牌格式，也可以使用作为承载令牌的访问令牌。
OpenID connect大多使用JWT作为令牌格式。
JWT是一种开放标准，它定义了一种紧凑且自成体系的方式，用于在各方之间安全地传输信息。这是一种身份验证协议，在该协议中，我们允许已编码的声明（令牌）在两方（客户端和服务器）之间进行传输，并且令牌是在识别客户端后发出的。对于每个后续请求，我们发送令牌。
OAuth2是一个授权框架，它具有该框架定义的一般过程和设置。JWT可以用作OAuth2内部的机制。
你可以在这里阅读更多
这个问题是一个普遍的问题，但不是很明智。JWT是令牌的一种，而OAuth是描述如何分配令牌的框架。
我们所说的“框架”是什么意思？可以并且应该用来请求令牌的只是请求和响应的顺序以及它们的格式。OAuthv2针对不同的场景描述了单独的“流”或授权类型，并具有不同的扩展名（例如PKCE）以扩展特定流的安全性。
通过OAuthV2许可进行令牌请求的结果是……令牌。然后将该东西用作“承载者令牌”，这意味着持有令牌的任何一方都可以在进行api请求服务时出示令牌（例如，“我的储值卡上的余额是多少？”）。作为不记名令牌，它的工作原理类似于现金。如果您拿着它，可以使用它。（尽管与现金不同，但代币不是用完即用的代币。也许更好的比喻是公交系统的全天乘车票或迪士尼世界的全天票。）
JWT是一种特殊的令牌，并且JWT绝对可以用作OAuth承载令牌。实际上，这是最常见的做法。有鉴于此，“ JWT与OAuth”是对苹果和购物车的比较。
通常，人们认为“ OAuth令牌”始终暗含一个不透明的令牌-不包含内在含义的字母数字字符的随机序列-由OAuth令牌药房授予，然后只能由同一OAuth药房系统进行验证。但这不是唯一的OAuth令牌。不透明令牌是一种令牌。JWT可以用作另一种OAuth令牌。
相反，JWT不是不透明的。JWT不是信息的“指针”或参考。它实际上包含许多特定信息，任何拥有令牌的一方都可以提取和解释这些信息。由于JWT包含真实信息，因此JWT可能很大。300字节，500字节或更多，取决于其中包含的声明以及用于对其签名的算法。当人们说“ JWT正在自我验证”的意思是，JWT的任何持有人都可以打开它，对其进行验证，然后根据其中提出的声明做出授权决定。验证JWT意味着：验证其结构，解码base64编码，验证密钥正确，验证签名，然后验证令牌中是否存在要求的声明，检查到期时间。这不是一件简单的事情，这是一个多步骤的过程，但是当然有很多支持各种编程语言的库，当然还有VerifyJWT策略可以帮助您在Apigee Edge API代理中完成此操作。关键是，任何持有者或接收者都可以验证令牌。因此，我们说JWT支持“联合身份验证”-任何人都可以生成令牌，并且任何人都可以读取和验证令牌。
自定义声明。JWT和不透明的OAuth令牌都可以携带有关主题的自定义声明。安全。两者都是不记名令牌。两者都需要作为秘密进行保护。到期。两者都可以标记为过期。两者都可以刷新。身份验证机制或经验。两者都可以呈现相同的用户体验。