JWT和OAuth身份验证之间的主要区别是什么？

Question

我有一个使用JWT的无状态身份验证模型的新SPA。我经常被要求为身份验证流引用OAuth，比如要求我为每个请求发送‘承载令牌'，而不是简单的令牌头，但我确实认为OAuth比简单的基于JWT的身份验证要复杂得多。主要区别是什么？我应该让JWT身份验证像OAuth一样运行吗？

我还使用JWT作为我的XSRF令牌来防止XSRF，但我被要求将它们分开？我应该把他们分开吗？这里的任何帮助都将得到赞赏，并可能为社区提供一套指导方针。

Answer 1

OAuth2.0定义了一个协议，即指定了令牌的传输方式，JWT定义了令牌格式。

当涉及到客户端向资源服务器提供令牌的（第二）阶段时，OAUTH2.0和“JWT身份验证”具有类似的外观：令牌在头中传递。

但是“JWT身份验证”并不是一个标准，并且没有指定客户机如何首先获得令牌（第一阶段）。这就是OAuth的复杂度的来源：它还定义了客户机可以从被称为授权服务器的东西获取访问令牌的各种方式。

所以真正的区别在于JWT只是一种令牌格式，OAUTH2.0是一种协议（可以使用JWT作为令牌格式）。

Answer 2

如果您有非常简单的场景，比如单个客户机应用程序、单个API，那么使用OAuth2.0可能不会有回报，另一方面，大量不同的客户机（基于浏览器的、本地移动的、服务器端的，等等），那么坚持OAuth2.0规则可能会比尝试运行您自己的系统更容易管理。

正如另一个答案中所述，JWT（Learn JSON Web令牌）只是一种令牌格式，它定义了一种紧凑的、自包含的机制，用于在各方之间以一种可以验证和信任的方式传输数据，因为它是数字签名的。此外，JWT的编码规则也使这些令牌在HTTP上下文中非常容易使用。

由于是自包含的（实际的令牌包含关于给定主题的信息），它们也是实现无状态身份验证机制的好选择（也就是Look mum，no Sessions！）。当通过此路由时，并且一方必须提供的唯一东西才能被授予对受保护资源的访问权限是令牌本身，则所讨论的令牌可称为承载令牌。

在实践中，你正在做的事情已经可以归类为基于承载令牌。但是，请考虑您没有使用OAuth2.0相关规范所指定的承载令牌（请参见RFC6750)。这意味着依赖于授权HTTP头并使用承载身份验证方案。

关于在不知道确切细节的情况下使用JWT来防止CSRF的问题，很难确定这种做法的有效性，但老实说，它似乎并不正确和/或值得。下面的文章（cookie vs tokens：Definitive Guide）可能是本主题的有用读物，特别是XSS和XSRF保护部分。

最后一条建议是，即使您不需要使用完整的OAuth2.0，我强烈建议您在authorization头中传递访问令牌，而不是使用自定义头。如果它们真的是承载令牌，请遵循RFC6750的规则。如果不是，则始终可以创建自定义身份验证方案，并且仍然使用该头。

HTTP代理和服务器会识别并特别处理授权头。因此，使用这样的报头将访问令牌发送到资源服务器降低了泄漏的可能性或一般的、特别是授权报头的经认证的请求的意外存储的可能性。

（来源：RFC 6819，第5.4.1节）