Tec*_*kie 276 authentication oauth jwt
我有一个使用JWT的无状态身份验证模型的新SPA.我经常被要求引用OAuth进行身份验证流程,例如要求我为每个请求发送"Bearer tokens"而不是简单的令牌标头,但我认为OAuth比简单的基于JWT的身份验证要复杂得多.如果JWT身份验证的行为与OAuth相似,主要区别是什么？
我也使用JWT作为我的XSRF-TOKEN以防止XSRF,但我被要求将它们分开？我应该将它们分开吗？这里的任何帮助将不胜感激,并可能为社区带来一套指导方针.
Joã*_*elo 253
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).这意味着,依赖于AuthorizationHTTP标头并使用Bearer身份验证方案.
关于使用JWT来防止CSRF而不知道确切的细节,很难确定该实践的有效性,但说实话,它似乎不正确和/或值得.以下文章(Cookies vs Tokens:The Definitive Guide)可能是关于此主题的有用读物,尤其是XSS和XSRF保护部分.
最后一条建议,即使您不需要完整的OAuth 2.0,我强烈建议您在Authorization标头内传递访问令牌,而不是使用自定义标头.如果它们确实是承载令牌,请遵循RFC 6750的规则,否则,您始终可以创建自定义身份验证方案并仍然使用该标头.
授权标头由HTTP代理和服务器识别并特别处理.因此,这种用于向资源服务器发送访问令牌的头部的使用降低了通常的认证请求的泄漏或无意存储的可能性,尤其是授权头部.
(来源:RFC 6819,第5.4.1节)
Han*_* Z. 222
OAuth 2.0定义了一个协议,即指定如何传输令牌,JWT定义了一种令牌格式.
当客户端将令牌呈现给资源服务器的第(2)阶段时,OAuth 2.0和"JWT身份验证"具有类似的外观:令牌在头部中传递.
但是"JWT身份验证"不是标准,并且没有指定客户端如何首先获取令牌(第1阶段).这就是感知OAuth的复杂性的地方:它还定义了客户端可以从称为授权服务器的东西获取访问令牌的各种方式.
所以真正的区别在于JWT只是一种令牌格式,OAuth 2.0是一种协议(可以使用JWT作为令牌格式).
Mel*_*şek 94
首先,我们必须区分JWT和OAuth.基本上,JWT是一种令牌格式.OAuth是一种授权协议,可以使用JWT作为令牌.OAuth使用服务器端和客户端存储.如果你想真正注销,你必须使用OAuth2.使用JWT令牌进行身份验证无法实际注销.因为您没有跟踪令牌的身份验证服务器.如果要向第三方客户端提供API,则还必须使用OAuth2.OAuth2非常灵活.JWT实现非常简单,实施起来不会太长.如果您的应用程序需要这种灵活性,那么您应该使用OAuth2.但是,如果您不需要此用例场景,则实施OAuth2是浪费时间.
XSRF令牌始终在每个响应头中发送到客户端.是否在JWT令牌中发送CSRF令牌无关紧要,因为CSRF令牌本身是安全的.因此,在JWT中发送CSRF令牌是不必要的.
Man*_*ngh 50
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/
man*_*nth 38
看起来每个在这里回答的人都错过了OAUTH的问题点
来自维基百科
OAuth是访问委派的开放标准,通常用作互联网用户授权网站或应用程序访问其他网站上的信息但不向他们提供密码的方式.[1] Google,Facebook,Microsoft和Twitter等公司使用此机制允许用户与第三方应用程序或网站共享有关其帐户的信息.
这里的关键点是access delegation.为什么有人会在存在基于id/pwd的身份验证时创建OAUTH,由多因素auth支持,如OTP,并且可以通过JWT保护,JWT用于保护对路径的访问(如OAUTH中的范围)并设置到期时间访问
如果消费者只通过他们在您的终点上再次托管的受信任网站(或应用程序)访问其资源(您的终点),则无需使用OAUTH
你可以去OAuth认证只是如果你是一个OAUTH provider在资源拥有者(用户)希望通过第三方客户端(外部应用程序)来访问他们的(你的)资源(终点)的情况下.它完全是为了相同的目的而创建的,尽管你可以滥用它
另一个重要的注意事项:
您可以自由地使用authenticationJWT和OAUTH 这个词,但都没有提供身份验证机制.是一个是令牌机制,另一个是协议,但一旦经过身份验证,它们仅用于授权(访问管理).您必须使用OPENID类型身份验证或您自己的客户端凭据来支持OAUTH
小智 13
找出 JWT 和 OAuth 之间的主要区别
OAuth 2.0 定义了协议，JWT 定义了令牌格式。
OAuth 可以使用 JWT 作为令牌格式或作为不记名令牌的访问令牌。
OpenID 连接大多使用 JWT 作为令牌格式。
JWT是一种身份验证协议,我们允许在两方(客户端和服务器)之间传输编码声明(令牌),并在识别客户端时发出令牌.随着每个后续请求,我们发送令牌.
而OAuth2是一个授权框架,它具有框架定义的一般过程和设置.JWT可以用作OAuth2中的机制.
你可以在这里阅读更多相关内容
| 归档时间： |
|
| 查看次数： |
199891 次 |
| 最近记录： |