我有一个使用JWT的无状态身份验证模型的新SPA。我经常被要求引用OAuth进行身份验证流程，比如要求我为每个请求发送“承载令牌”，而不是简单的令牌头，但我确实认为OAuth比简单的基于JWT的身份验证要复杂得多。主要的区别是什么，我应该让JWT身份验证像OAuth一样吗?
我还使用JWT作为我的XSRF- token来防止XSRF，但我被要求将它们分开?我应该把它们分开吗?这里的任何帮助都将受到感谢，并可能为社区提供一套指导方针。
当前回答
JWT (JSON Web令牌)——它只是一种令牌格式。JWT令牌是JSON编码的数据结构，包含有关发行者、主题(索赔)、到期时间等信息。对它进行签名以防止篡改和真实性，并且可以使用对称或非对称方法对它进行加密以保护令牌信息。JWT比SAML 1.1/2.0更简单，所有设备都支持它，而且它比SWT(简单Web令牌)更强大。
OAuth2 - OAuth2解决了用户想要使用客户端软件访问数据的问题，如基于浏览的web应用程序，本地移动应用程序或桌面应用程序。OAuth2仅用于授权，可以通过访问令牌授权客户端软件代表最终用户访问资源。
OpenID连接- OpenID连接构建在OAuth2之上，并添加身份验证。OpenID Connect向OAuth2添加了一些约束，如UserInfo端点、ID令牌、OpenID Connect提供程序的发现和动态注册以及会话管理。JWT是令牌的强制格式。
CSRF保护-如果您不将令牌存储在浏览器的cookie中，则不需要实现CSRF保护。
其他回答
OAuth 2.0定义了一个协议，即指定了令牌如何传输，JWT定义了令牌格式。
OAuth 2.0和“JWT身份验证”在客户端向资源服务器提供令牌的(第二)阶段具有类似的外观:令牌在头文件中传递。
但是“JWT身份验证”不是一个标准，并且没有指定客户端首先如何获得令牌(第一阶段)。这就是OAuth复杂性的来源:它还定义了客户端从所谓的授权服务器获取访问令牌的各种方式。
因此，真正的区别在于JWT只是一种令牌格式，OAuth 2.0是一种协议(可以使用JWT作为令牌格式)。
Firstly, we have to differentiate JWT and OAuth. Basically, JWT is a token format. OAuth is an authorization protocol that can use JWT as a token. OAuth uses server-side and client-side storage. If you want to do real logout you must go with OAuth2. Authentication with JWT token can not logout actually. Because you don't have an Authentication Server that keeps track of tokens. If you want to provide an API to 3rd party clients, you must use OAuth2 also. OAuth2 is very flexible. JWT implementation is very easy and does not take long to implement. If your application needs this sort of flexibility, you should go with OAuth2. But if you don't need this use-case scenario, implementing OAuth2 is a waste of time.
XSRF令牌总是在每个响应头中发送给客户端。CSRF令牌是否在JWT令牌中发送并不重要，因为CSRF令牌本身是安全的。因此，在JWT中发送CSRF令牌是不必要的。
找出JWT和OAuth之间的主要区别
OAuth 2.0定义了一个协议，JWT定义了一个令牌格式。 OAuth既可以使用JWT作为令牌格式，也可以使用访问令牌作为承载令牌。 OpenID连接大多使用JWT作为令牌格式。
JWT tokens require, at most, a one-time communication between the resource server and the authorization server at runtime. The resource server needs to request the authorization server for the public key to decrypt the JWT tokens. This can be done at resource server startup. This can even be stored in the resource server in a properties file avoiding the query at all. OAuth2 solve a problem that user wants to access the data using client software like browser-based web apps, native mobile apps, or desktop apps. OAuth2 is just for authorization, client software can be authorized to access the resources on behalf of end-user using an access token. OAuth2 can be used with JWT tokens or access token which is a bearer token.
博士TL; 如果您有非常简单的场景，比如单个客户端应用程序，单个API，那么使用OAuth 2.0可能并不值得。另一方面，如果有很多不同的客户端(基于浏览器的、本地移动的、服务器端等)，那么坚持OAuth 2.0规则可能比尝试使用自己的系统更容易管理。
正如在另一个回答中所述，JWT(学习JSON Web令牌)只是一种令牌格式。它定义了一个紧凑且自包含的机制，用于在各方之间以一种可验证和可信的方式传输数据，因为它是数字签名的。此外，JWT的编码规则也使这些令牌在HTTP上下文中非常容易使用。
它们是自包含的(实际令牌包含关于给定主题的信息)，也是实现无状态身份验证机制(又名Look mum, no session !)的好选择。在走这条路线时，一方要被授予对受保护资源的访问权，必须提供的唯一东西就是令牌本身，而所讨论的令牌可以称为不记名令牌。
在实践中，您所做的事情已经可以归类为基于不记名令牌的。但是，请考虑您没有使用OAuth 2.0相关规范指定的不记名令牌(请参阅RFC 6750)。这意味着依赖于Authorization HTTP报头并使用承载身份验证方案。
关于使用JWT来防止CSRF:在不知道确切细节的情况下，很难确定这种做法的有效性。说实话，这似乎不正确和/或不值得。下面的文章(cookie vs .令牌:最终指南)可能是关于这个主题的有用读物，特别是XSS和XSRF保护部分。
最后一条建议。即使您不需要完全使用OAuth 2.0，我也强烈建议您在授权标头中传递访问令牌，而不是使用自定义标头。如果它们确实是不记名代币，请遵循RFC 6750的规则。如果不是，您总是可以创建一个自定义身份验证方案，并仍然使用该报头。
授权标头由HTTP代理和服务器识别和特殊处理。因此，使用这样的头向资源服务器发送访问令牌，通常可以减少泄漏或意外存储经过身份验证的请求的可能性，特别是授权头。
(来源:RFC 6819，章节5.4.1)
