JWT和OAuth身份验证之间的主要区别是什么? [英] What are the main differences between JWT and OAuth authentication?

问题描述

我有一个新的SPA，具有使用JWT的无状态身份验证模型.我经常被要求将OAuth用于身份验证流程，例如要求我为每个请求发送承载者令牌"，而不是简单的令牌头，但是我确实认为OAuth比简单的基于JWT的身份验证复杂得多.主要区别是什么，我应该使JWT身份验证表现得像OAuth吗?

I have a new SPA with a stateless authentication model using JWT. I am often asked to refer OAuth for authentication flows like asking me to send 'Bearer tokens' for every requests instead of a simple token header but I do think that OAuth is lot more complex than a simple JWT based authentication. What are the main differences, should I make the JWT authentication behave like OAuth?

我还使用JWT作为我的XSRF-TOKEN来防止XSRF，但是我被要求将它们分开?我应该把它们分开吗?在此提供的任何帮助将不胜感激，并可能会为社区带来一系列指导.

I am also using the JWT as my XSRF-TOKEN to prevent XSRF but I am being asked to keep them separate? Should I keep them separate? Any help here will be appreciated and might lead to a set of guidelines for the community.

推荐答案

TL; DR 如果您有非常简单的场景，例如单个客户端应用程序，单个API，那么使用OAuth 2.0可能没有回报，另一方面，使用许多不同的客户端(基于浏览器的，本机移动的，服务器端的等等)那么坚持使用OAuth 2.0规则可能比尝试滚动自己的系统更易于管理.

TL;DR If you have very simple scenarios, like a single client application, a single API then it might not pay off to go OAuth 2.0, on the other hand, lots of different clients (browser-based, native mobile, server-side, etc) then sticking to OAuth 2.0 rules might make it more manageable than trying to rolling your own system.

如另一个答案所述，JWT(了解JSON网络令牌)只是它是一种令牌格式，它定义了一种紧凑且自包含的机制，可以通过一种经过验证和信任的方式在各方之间传输数据，因为它是经过数字签名的.此外，JWT的编码规则还使这些令牌在HTTP上下文中非常易于使用.

As stated in another answer, JWT (Learn JSON Web Tokens) is just a token format, it defines a compact and self-contained mechanism for transmitting data between parties in a way that can be verified and trusted because it is digitally signed. Additionally, the encoding rules of a JWT also make these tokens very easy to use within the context of HTTP.

自成一体(实际令牌包含有关给定主题的信息)，它们也是实现无状态身份验证机制(aka 看妈妈，没有会话！)的不错选择.当走这条路线时，要授予一方访问被保护资源的唯一条件就是令牌本身，有问题的令牌可以称为不记名令牌.

Being self-contained (the actual token contains information about a given subject) they are also a good choice for implementing stateless authentication mechanisms (aka Look mum, no sessions!). When going this route and the only thing a party must present to be granted access to a protected resource is the token itself, the token in question can be called a bearer token.

在实践中，您所做的已可以基于承载令牌进行分类.但是，请确保您未使用OAuth 2.0相关规范所指定的承载令牌(请参阅 RFC 6750 ).这意味着要依靠Authorization HTTP标头并使用Bearer身份验证方案.

In practice, what you're doing can already be classified as based on bearer tokens. However, do consider that you're not using bearer tokens as specified by the OAuth 2.0 related specs (see RFC 6750). That would imply, relying on the Authorization HTTP header and using the Bearer authentication scheme.

关于在不知道确切细节的情况下使用JWT来防止CSRF的情况，很难确定该做法的有效性，但是说实话，这似乎并不正确和/或不值得.以下文章( Cookies vs Tokens:权威指南)是有关此主题的有用读物，尤其是 XSS和XSRF保护部分.

Regarding the use of the JWT to prevent CSRF without knowing exact details it's difficult to ascertain the validity of that practice, but to be honest it does not seem correct and/or worthwhile. The following article (Cookies vs Tokens: The Definitive Guide) may be a useful read on this subject, particularly the XSS and XSRF Protection section.

最后一条建议，即使您不需要完整的OAuth 2.0，我也强烈建议您在Authorization标头中传递访问令牌，而不要使用自定义标头 .如果它们确实是承载令牌，则遵循RFC 6750的规则，否则，您始终可以创建自定义身份验证方案，并仍然使用该标头.

One final piece of advice, even if you don't need to go full OAuth 2.0, I would strongly recommend on passing your access token within the Authorization header instead of going with custom headers. If they are really bearer tokens follow the rules of RFC 6750, if not, you can always create a custom authentication scheme and still use that header.

授权标头由HTTP代理和服务器识别并特别处理.因此，使用此类标头将访问令牌发送到资源服务器通常会降低身份验证请求(特别是授权标头)泄漏或意外存储的可能性.

Authorization headers are recognized and specially treated by HTTP proxies and servers. Thus, the usage of such headers for sending access tokens to resource servers reduces the likelihood of leakage or unintended storage of authenticated requests in general, and especially Authorization headers.

(来源: RFC 6819，第5.4.1节)

这篇关于JWT和OAuth身份验证之间的主要区别是什么?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！