我有一个使用JWT的无状态身份验证模型的新SPA。我经常被要求将OAuth用于身份验证流程，例如要求我为每个请求发送“Bearer tokens”而不是简单的令牌标头，但我认为OAuth比简单的基于JWT的身份验证要复杂得多。如果JWT身份验证的行为与OAuth相似，主要区别是什么？
我也使用JWT作为我的XSRF-TOKEN以防止XSRF，但我被要求将它们分开？我应该将它们分开吗？这里的任何帮助将不胜感激，并可能为社区制定一套指导方针。
答案 0 :(得分：210)
<强> TL; DR 如果您有非常简单的场景，例如单个客户端应用程序，单个API，那么它可能无法获得OAuth 2.0，另一方面，许多不同的客户端（基于浏览器，本机移动，服务器端等）然后坚持使用OAuth 2.0规则可能会比尝试滚动自己的系统更易于管理。
如另一个答案中所述，JWT（Learn JSON Web Tokens）只是一种令牌格式，它定义了一种紧凑且独立的机制，用于以可以验证和信任的方式在各方之间传输数据，因为它是数字化的签。此外，JWT的编码规则也使这些令牌在HTTP环境中非常容易使用。
自包含（实际令牌包含有关给定主题的信息），它们也是实现无状态身份验证机制（又名 Look mum，no sessions！）的不错选择。当走这条路线时，一方必须呈现以被授予访问受保护资源的唯一权限就是令牌本身，所讨论的令牌可称为持票令牌。
在实践中，您所做的事情已经可以根据持有人令牌进行分类。但是，请考虑您未使用OAuth 2.0相关规范中指定的承载令牌（请参阅RFC 6750）。这意味着，依赖于Authorization HTTP标头并使用Bearer身份验证方案。
关于使用JWT在不知道具体细节的情况下防止CSRF，很难确定该实践的有效性，但说实话，它似乎不正确和/或值得。以下文章（Cookies vs Tokens: The Definitive Guide）可能对此主题有用，尤其是 XSS和XSRF Protection 部分。
最后一条建议，即使您不需要使用完整的OAuth 2.0，我强烈建议您在Authorization标头内传递访问令牌，而不是使用自定义标头即可。如果它们确实是承载令牌，请遵循RFC 6750的规则，否则，您始终可以创建自定义身份验证方案并仍然使用该标头。
HTTP代理和服务器识别并特殊处理授权标头。因此，使用这种标头向资源服务器发送访问令牌可以降低一般情况下泄漏或无意中存储经过身份验证的请求的可能性，尤其是授权标头。
答案 1 :(得分：181)
OAuth 2.0定义了一个协议，即指定如何传输令牌，JWT定义了一种令牌格式。
OAuth 2.0和＆＃34; JWT身份验证＆＃34;客户端将令牌提供给资源服务器的（第二）阶段具有类似的外观：令牌在头部中传递。
但是＆＃34; JWT认证＆＃34;不是标准，也没有指定客户端首先获取令牌的 （第一阶段）。这就是感知OAuth的复杂性的地方：它还定义了客户端可以从称为授权服务器的某些东西获取访问令牌的各种方式。
所以真正的区别在于JWT只是一种令牌格式，OAuth 2.0是一种协议（可能使用JWT作为令牌格式）。
答案 2 :(得分：82)
首先，我们必须区分JWT和OAuth。基本上，JWT是一种令牌格式。 OAuth是一种授权协议，可以使用JWT作为令牌。 OAuth使用服务器端和客户端存储。如果你想真正注销，你必须使用OAuth2。使用JWT令牌进行身份验证无法实际注销。因为您没有跟踪令牌的身份验证服务器。如果要向第三方客户端提供API，则还必须使用OAuth2。 OAuth2非常灵活。 JWT实现非常简单，实施起来不会太长。如果您的应用程序需要这种灵活性，那么您应该使用OAuth2。但是，如果您不需要这种用例场景，那么实施OAuth2是浪费时间。
XSRF令牌始终在每个响应头中发送到客户端。是否在JWT令牌中发送CSRF令牌无关紧要，因为CSRF令牌本身是安全的。因此，在JWT中发送CSRF令牌是不必要的。
答案 3 :(得分：42)
JWT（JSON Web令牌） - 它只是一种令牌格式。 JWT令牌是JSON编码的数据结构，包含有关发行者，主题（声明），到期时间等的信息。它被签名用于防篡改和真实性，并且可以使用对称或非对称方法对其进行加密以保护令牌信息。 JWT比SAML 1.1 / 2.0更简单，并且得到所有设备的支持，它比SWT（简单Web令牌）更强大。
OAuth2 - OAuth2解决了用户希望使用客户端软件（如基于浏览的网络应用，原生移动应用或桌面应用）访问数据的问题。 OAuth2仅用于授权，可以授权客户端软件代表最终用户使用访问令牌访问资源。
OpenID Connect - OpenID Connect构建于OAuth2之上并添加身份验证。 OpenID Connect向OAuth2添加一些约束，如UserInfo端点，ID令牌，OpenID Connect提供程序的发现和动态注册以及会话管理。 JWT是令牌的强制格式。
CSRF保护 - 如果您不在浏览器的Cookie中存储令牌，则无需实施CSRF保护。
了解更多详情答案 4 :(得分：30)
看起来每个在这里回答的人都错过了OAUTH的问题点
来自维基百科
OAuth是一种开放的访问委派标准，通常用作互联网用户授权网站或应用程序访问其他网站上的信息但不向他们提供密码的方式。[1] Google，Facebook，Microsoft和Twitter等公司使用此机制允许用户与第三方应用程序或网站共享有关其帐户的信息。
这里的关键点是access delegation。为什么有人会在存在基于id / pwd的身份验证时创建OAUTH，由多因素auth支持，如OTP，并且可以通过JWT保护，JWT用于保护对路径的访问（如OAUTH中的范围）并设置到期时间访问
如果消费者只通过他们在您的终点上再次托管的受信任网站（或应用程序）访问他们的资源（您的终点），那么就没有必要使用OAUTH
如果您是资源所有者（用户）想要通过第三方客户端访问其（您的）资源（端点）的情况下的OAUTH provider，则只能进行OAUTH身份验证（外部应用程序）。它完全是为了相同的目的而创建的，尽管你可以滥用它
另一个重要说明：
您可以自由地将单词authentication用于JWT和OAUTH，但都不提供身份验证机制。是一个是令牌机制，另一个是协议，但一旦经过身份验证，它们仅用于授权（访问管理）。您可以使用OPENID类型身份验证或您自己的客户端凭据来支持OAUTH
答案 5 :(得分：5)
JWT是一种开放标准，它定义了一种紧凑且独立的方式，可以在各方之间安全地传输信息。它是一种身份验证协议，我们允许在两方（客户端和服务器）之间传输编码声明（令牌），并在识别客户端时发出令牌。随着每个后续请求，我们发送令牌。
OAuth2是一个授权框架，它具有框架定义的一般过程和设置。 JWT可以用作OAuth2中的一种机制。
您可以在此处详细了解
答案 6 :(得分：5)
这个问题很常见，但是不太明智。 JWT是令牌的一种，而OAuth是描述如何分配令牌的框架。
“框架”是什么意思？可以并且应该用来请求令牌的只是请求和响应的顺序以及它们的格式。 OAuthv2针对不同情况描述了单独的“流”或授权类型，并具有用于扩展特定流安全性的不同扩展（例如PKCE）。
通过OAuthV2许可进行令牌请求的结果是...令牌。然后将该东西用作“承载者令牌”，这意味着持有令牌的任何一方都可以在进行api请求服务时出示令牌（例如，“我的储值卡上的余额是多少？”）。作为不记名令牌，它的工作原理类似于现金。如果您拿着它，可以使用它。 （尽管与现金不同，但代币不是用完即失的。也许更好的比喻是公交系统上的全日票或迪斯尼乐园的全天票。） / p>
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令牌都可以携带有关主题的自定义声明。 安全。两者都是不记名令牌。两者都需要作为秘密受到保护。 到期。两者都可以标记为过期。两者都可以刷新。 身份验证机制或经验。两者都可以提供相同的用户体验。
答案 7 :(得分：0)
Jwt是一套严格的指令，用于签发和验证签名访问令牌。令牌包含应用程序用于限制对用户的访问权限的声明
另一方面，OAuth2不是协议，它是委托授权框架。考虑非常详细的准则，让用户和应用程序在私人和公共设置中授权其他应用程序的特定权限。位于OAUTH2之上的OpenID Connect为您提供身份验证和授权。详细说明了多个不同角色，系统中的用户，服务器端应用程序（如API）以及客户端（如网站或本机移动应用程序）如何对每个角色进行身份验证注意 oauth2可以使用jwt，灵活实现，可以扩展到不同的应用程序
答案 8 :(得分：0)
发现JWT和OAuth之间的主要区别
OAuth 2.0定义了协议，而JWT定义了令牌格式。
OAuth可以使用JWT作为令牌格式，也可以使用作为承载令牌的访问令牌。
OpenID connect大多使用JWT作为令牌格式。