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

问题描述

我有一个使用 JWT 的带有无状态身份验证模型的新 SPA.我经常被要求将 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 request instead of a simple token header but I do think that OAuth is a 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 roll your own system.

如另一个答案所述，JWT(Learn JSON Web Tokens)只是一种令牌格式，它定义了一种紧凑且自包含的机制，用于在各方之间以一种可以验证和信任的方式传输数据，因为它是经过数字签名的.此外，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.

自包含(实际令牌包含有关给定主题的信息)它们也是实现无状态身份验证机制(又名妈妈，没有会话！)的不错选择.走这条路时，一方必须出示才能获得对受保护资源的访问权的唯一东西就是令牌本身，有问题的令牌可以称为不记名令牌.

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 相关规范指定的不记名令牌(请参阅 RFC6750).这意味着，依赖 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: The Definitive Guide)可能是有关此主题的有用读物，尤其是 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屋！