我有一个使用JWT的无状态身份验证模型的新SPA。我经常被要求引用OAuth进行身份验证流程,比如要求我为每个请求发送“承载令牌”,而不是简单的令牌头,但我确实认为OAuth比简单的基于JWT的身份验证要复杂得多。主要的区别是什么,我应该让JWT身份验证像OAuth一样吗?
我还使用JWT作为我的XSRF- token来防止XSRF,但我被要求将它们分开?我应该把它们分开吗?这里的任何帮助都将受到感谢,并可能为社区提供一套指导方针。
首先,我们必须区分JWT和OAuth。基本上,JWT是一种令牌格式。OAuth是一种可以使用JWT作为令牌的授权协议。OAuth使用服务器端和客户端存储。如果你想要真正的注销,你必须使用OAuth2。使用JWT令牌进行身份验证实际上不能注销。因为您没有跟踪令牌的身份验证服务器。如果你想为第三方客户端提供API,你也必须使用OAuth2。OAuth2非常灵活。JWT的实现非常简单,并且不需要很长时间来实现。如果您的应用程序需要这种灵活性,那么您应该使用OAuth2。但是如果您不需要这个用例场景,那么实现OAuth2就是浪费时间。
XSRF令牌总是在每个响应头中发送给客户端。CSRF令牌是否在JWT令牌中发送并不重要,因为CSRF令牌本身是安全的。因此,在JWT中发送CSRF令牌是不必要的。
OAuth 2.0定义了一个协议,即指定了令牌如何传输,JWT定义了令牌格式。
OAuth 2.0和“JWT身份验证”在客户端向资源服务器提供令牌的(第二)阶段具有类似的外观:令牌在头文件中传递。
但是“JWT身份验证”不是一个标准,并且没有指定如何,客户端首先获得令牌(第一阶段)。这就是OAuth复杂性的来源:它还定义了客户端从所谓的授权服务器获取访问令牌的各种方式。
所以真正的区别是JWT只是一种令牌格式,OAuth 2.0是一种协议(五月使用JWT作为令牌格式)。
< >强TL,博士 如果您有非常简单的场景,比如单个客户端应用程序,单个API,那么使用OAuth 2.0可能并不值得。另一方面,如果有很多不同的客户端(基于浏览器的、本地移动的、服务器端等),那么坚持OAuth 2.0规则可能比尝试使用自己的系统更容易管理
正如在另一个答案中所述,JWT (了解JSON Web令牌)只是一种令牌格式。它定义了一个紧凑且自包含的机制,用于在各方之间以一种可验证和可信的方式传输数据,因为它是数字签名的。此外,JWT的编码规则也使这些令牌在HTTP上下文中非常容易使用。
它们是自包含的(实际令牌包含关于给定主题的信息),也是实现无状态身份验证机制(又名看,妈妈,没有疗程!)的好选择。在走这条路线时,一方要被授予对受保护资源的访问权,必须提供的唯一东西就是令牌本身,而所讨论的令牌可以称为不记名令牌。
在实践中,您所做的事情已经可以归类为基于不记名令牌的。但是,请考虑您没有使用OAuth 2.0相关规范指定的不记名令牌(参见RFC 6750)。这意味着依赖于Authorization HTTP报头并使用Bearer身份验证方案。
Authorization
Bearer
关于使用JWT来防止CSRF:在不知道确切细节的情况下,很难确定这种做法的有效性。说实话,这似乎不正确和/或不值得。下面的文章(cookie vs .令牌:权威指南)可能是关于这个主题的有用阅读,特别是XSS和XSRF保护部分。
最后一条建议。即使你不需要完全的OAuth 2.0,我你强烈建议在Authorization头中传递你的访问令牌,而不是使用自定义头。如果它们确实是不记名代币,请遵循RFC 6750的规则。如果不是,您总是可以创建一个自定义身份验证方案,并仍然使用该报头。
授权标头由HTTP代理和服务器识别和特殊处理。因此,使用这样的头向资源服务器发送访问令牌,通常可以减少泄漏或意外存储经过身份验证的请求的可能性,特别是授权头。
(来源:# EYZ0)
看起来每个回答这里的人都错过了OAUTH的关键
从维基百科
OAuth是一种访问授权的开放标准,通常用于互联网用户授权网站或应用程序访问他们在其他网站上的信息,但不提供密码谷歌、Facebook、微软和Twitter等公司都使用这种机制,允许用户与第三方应用程序或网站分享有关其账户的信息。
这里的关键点是access delegation。当存在基于id/pwd的身份验证时,为什么还要创建OAUTH呢?它由多因素身份验证(如otp)支持,并且可以通过用于保护路径访问(如OAUTH中的作用域)并设置访问过期的jwt进行保护
access delegation
如果消费者只能通过他们信任的网站(或应用程序)访问他们的资源(您的端点),那么使用OAUTH就没有意义了,而这些网站又托管在您的端点上
你可以只使用OAUTH认证如果你是OAUTH provider,资源所有者(用户)想通过第三方客户端(外部应用程序)访问他们(你的)资源(端点)。,它完全是为了同样的目的而创建的,尽管你可以滥用它
OAUTH provider
authentication
JWT (JSON Web令牌)-它只是一个令牌格式。JWT令牌是JSON编码的数据结构,包含有关发行者、主题(索赔)、到期时间等信息。对它进行签名以防止篡改和真实性,并且可以使用对称或非对称方法对它进行加密以保护令牌信息。JWT比SAML 1.1/2.0更简单,所有设备都支持它,而且它比SWT(简单Web令牌)更强大。
OAuth2 - OAuth2解决了用户想要使用客户端软件访问数据的问题,比如基于浏览的web应用程序,本地移动应用程序或桌面应用程序。OAuth2仅用于授权,可以通过访问令牌授权客户端软件代表最终用户访问资源。
OpenID连接 - OpenID连接构建在OAuth2之上,并添加了身份验证。OpenID Connect向OAuth2添加了一些约束,如UserInfo端点、ID令牌、OpenID Connect提供程序的发现和动态注册以及会话管理。JWT是令牌的强制格式。
CSRF保护 -如果您没有在浏览器的cookie中存储令牌,则不需要实现CSRF保护。
Jwt是一组用于发布和验证已签名访问令牌的严格指令。令牌包含应用程序用来限制用户访问的声明
另一方面,OAuth2不是一个协议,它是一个委托授权框架。考虑非常详细的指导方针,允许用户和应用程序在私有和公共设置中向其他应用程序授权特定的权限。OpenID连接位于OAUTH2之上,为您提供身份验证和授权。它详细说明了多个不同的角色,系统中的用户,服务器端应用程序(如API),以及客户端(如网站或本地移动应用程序)如何相互验证
请注意 oauth2可以与jwt一起工作,实现灵活,可扩展到不同的应用程序
JWT是一个开放标准,它定义了一种紧凑且自包含的方式,用于在各方之间安全地传输信息。这是一种身份验证协议,我们允许编码的声明(令牌)在双方(客户端和服务器)之间传输,令牌在客户端识别时发出。对于每个后续请求,我们发送令牌。
而OAuth2是一个授权框架,它具有框架定义的一般过程和设置。JWT可以用作OAuth2中的一种机制。
你可以在这里阅读更多
OAuth or JWT?使用哪一个,为什么?< / >
找出智威汤逊和amp;OAuth
OAuth 2.0定义了一个协议JWT定义了一种令牌格式。
OAuth既可以使用JWT作为令牌格式,也可以使用访问令牌作为承载令牌。
OpenID连接大多使用JWT作为令牌格式。
JWT令牌要求资源服务器和授权服务器在运行时最多进行一次通信。的 资源服务器需要向授权服务器请求 公钥来解密JWT令牌。这可以在资源中完成 服务器启动。甚至可以将其存储在资源服务器中的
OAuth2解决了用户想要使用客户端软件访问数据的问题,如基于浏览器的web应用程序,本地移动应用程序,或 桌面应用程序。OAuth2只是用于授权,客户端软件可以 被授权代表最终用户访问资源 访问令牌。< / p >