authentication - jwt框架 - springboot jwt




JWT和OAuth身份验证之间的主要区别是什么? (6)

我有一个使用JWT的无状态身份验证模型的新SPA。 我经常被要求引用OAuth进行身份验证流程,例如要求我为每个请求发送“Bearer tokens”而不是简单的令牌标头,但我认为OAuth比简单的基于JWT的身份验证要复杂得多。 如果JWT身份验证的行为与OAuth相似,主要区别是什么?

我也使用JWT作为我的XSRF-TOKEN以防止XSRF,但我被要求将它们分开? 我应该将它们分开吗? 这里的任何帮助将不胜感激,并可能为社区带来一套指导方针。


JWT是一种开放标准,它定义了一种紧凑且独立的方式,用于在各方之间安全地传输信息。 它是一种身份验证协议,我们允许在两方(客户端和服务器)之间传输编码声明(令牌),并在识别客户端时发出令牌。 随着每个后续请求,我们发送令牌。

而OAuth2是一个授权框架,它具有框架定义的一般过程和设置。 JWT可以用作OAuth2中的机制。

你可以在这里阅读更多相关内容

OAuth还是JWT? 哪一个使用,为什么?


Jwt是一套严格的指令,用于签发和验证签名访问令牌。 令牌包含应用程序用于限制对用户的访问权限的声明

另一方面,OAuth2不是协议,它是委托授权框架。 考虑非常详细的准则,让用户和应用程序在私人和公共设置中授权其他应用程序的特定权限。 位于OAUTH2之上的OpenID Connect为您提供身份验证和授权。详细说明了多个不同的角色,系统中的用户,服务器端应用程序(如API)以及客户端(如网站或本机移动应用程序)如何与其他人进行身份验证

注意 oauth2可以使用jwt,灵活的实现,可以扩展到不同的应用程序


找到JWT和OAuth之间的主要区别

  1. OAuth 2.0定义了协议,JWT定义了令牌格式。

  2. OAuth可以使用JWT作为令牌格式,也可以使用作为承载令牌的访问令牌。

  3. OpenID连接主要使用JWT作为令牌格式。


看起来每个在这里回答的人都错过了OAUTH的问题点

来自维基百科

OAuth是访问委派的开放标准,通常用作互联网用户授权网站或应用程序访问其他网站上的信息但不向他们提供密码的方式。[1] Google,Facebook,Microsoft和Twitter等公司使用此机制允许用户与第三方应用程序或网站共享有关其帐户的信息。

这里的关键点是 access delegation 。 为什么有人会在存在基于id / pwd的身份验证时创建OAUTH,由多因素auth支持,如OTP,并且可以通过JWT保护,JWT用于保护对路径的访问(如OAUTH中的范围)并设置到期时间访问

如果消费者只通过他们在您的终点上再次托管的受信任网站(或应用程序)访问其资源(您的终点),则无需使用OAUTH

只有 在资源所有者(用户)希望通过第三方客户端(外部应用程序)访问其(您的)资源(端点)的情况下, 您才能进行OAUTH身份验证 它完全是为了相同的目的而创建的,尽管你可以滥用它

另一个重要说明:
你可以自由地为JWT和OAUTH使用单词 authentication ,但是它们都没有提供身份验证机制。 是一个是令牌机制,另一个是协议,但一旦经过身份验证,它们仅用于授权(访问管理)。 您必须使用OPENID类型身份验证或您自己的客户端凭据来支持OAUTH


JWT(JSON Web令牌) - 它只是一种令牌格式。 JWT令牌是JSON编码的数据结构,包含有关发行者,主题(声明),到期时间等的信息。它被签名用于防篡改和真实性,并且可以使用对称或非对称方法对其进行加密以保护令牌信息。 JWT比SAML 1.1 / 2.0更简单,并且受到所有设备的支持,并且它比SWT(简单Web令牌)更强大。

OAuth2 - OAuth2解决了用户希望使用客户端软件(如基于浏览的Web应用程序,本机移动应用程序或桌面应用程序)访问数据的问题。 OAuth2仅用于授权,可以授权客户端软件代表最终用户使用访问令牌访问资源。

OpenID Connect - OpenID Connect构建于OAuth2之上并添加身份验证。 OpenID Connect向OAuth2添加一些约束,如UserInfo端点,ID令牌,OpenID Connect提供程序的发现和动态注册以及会话管理。 JWT是令牌的强制格式。

CSRF保护 - 如果您不在浏览器的cookie中存储令牌,则无需实施CSRF保护。

您可以在此处阅读更多详细信息 http://proficientblog.com/microservices-security/


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保护 部分。

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

授权标头由HTTP代理和服务器识别并进行特殊处理。 因此,这种用于向资源服务器发送访问令牌的头部的使用降低了通常的认证请求的泄漏或无意存储的可能性,尤其是授权头部。

(来源: RFC 6819,第5.4.1节







jjwt