OAuth 2与OAuth 1有何不同？

Question

用非常简单的术语来说,有人可以解释OAuth 2和OAuth 1之间的区别吗？

OAuth 1现在已经过时了吗？应该实施OAuth 2吗？我没有看到很多OAuth 2的实现; 大多数人仍在使用OAuth 1,这让我怀疑OAuth 2已经可以使用了.是吗？

Answer 1

Eran Hammer-Lahav在他的文章" 介绍OAuth 2.0"中解释了大部分差异方面做得非常出色.总而言之,以下是主要区别:

更多OAuth流程可以更好地支持非基于浏览器的应用程序. 这是对来自非基于浏览器的客户端应用程序的OAuth的主要批评.例如,在OAuth 1.0中,桌面应用程序或移动电话应用程序必须指示用户将浏览器打开到所需服务,对服务进行身份验证,然后将令牌从服务复制回应用程序.这里的主要批评是反对用户体验.使用OAuth 2.0,现在有一种新的方法可以让应用程序获得用户授权.

OAuth 2.0不再要求客户端应用程序具有加密功能. 这回到了旧的Twitter Auth API,它不需要应用程序HMAC哈希令牌和请求字符串.使用OAuth 2.0,应用程序可以仅使用HTTPS上发布的令牌发出请求.

OAuth 2.0签名要简单得多.不再需要特殊的解析,排序或编码.

OAuth 2.0访问令牌是"短命的".通常,OAuth 1.0 Access令牌可以存储一年或更长时间(Twitter永远不会让它们过期).OAuth 2.0具有刷新令牌的概念.虽然我不完全确定这些是什么,但我的猜测是你的访问令牌可能是短暂的(即基于会话)而你的刷新令牌可能是"生命时间".您将使用刷新令牌获取新的访问令牌,而不是让用户重新授权您的应用程序.

最后,OAuth 2.0旨在将负责处理OAuth请求的服务器与处理用户授权的服务器之间的角色清晰分离. 有关详细信息,请参阅上述文章.

Answer 2

我在这里看到了很好的答案,但我想念的是一些图表,因为我不得不使用Spring Framework,我遇到了他们的解释.

我发现以下图表非常有用.它们说明了OAuth2和OAuth1之间的通信差异.

OAuth 2

OAuth 1

Answer 3

以前的解释都是过于详细和复杂的IMO.简而言之,OAuth 2将安全性委托给HTTPS协议.OAuth 1并不需要这样,因此可以采用其他方法来处理各种攻击.这些方法要求应用程序参与某些复杂且难以实现的安全协议.因此,仅依靠HTTPS来实现安全性更加简单,以便应用程序开发人员不必担心它.

至于你的其他问题,答案取决于.有些服务不想要求使用HTTPS,在OAuth 2之前开发,或者有一些其他要求可能会阻止他们使用OAuth 2.此外,关于OAuth 2协议本身存在很多争议.正如您所看到的,Facebook,Google和其他一些人都实施了略有不同版本的协议.因此有些人坚持使用OAuth 1,因为它在不同平台上更加统一.最近,OAuth 2协议已经完成,但我们还没有看到它的采用方式.

Answer 4

请注意,使用Oauth 2存在严重的安全性论点:

一篇凄凉的文章

而且更技术性

请注意,这些来自Oauth 2的主要作者.

关键点:

• Oauth 2在SSL之上不提供安全性,而Oauth 1与传输无关.

• 从某种意义上说,SSL并不安全,因为服务器不验证连接,而公共客户端库可以轻松忽略故障.

  SSL/TLS的问题在于,当您无法在客户端验证证书时,连接仍然有效.任何时候忽略错误都会导致成功,开发人员会这样做.服务器无法执行证书验证,即使可能,攻击者肯定不会.

• 你可以贬低你的所有安全性,这在OAuth 1.0中更难做到:

  第二个常见的潜在问题是拼写错误.如果省略一个字符('https'中的's'),你会认为它是一个合适的设计会使令牌的整个安全性无效吗？或者可能将请求(通过有效且经过验证的SSL/TLS连接)发送到错误的目的地(例如" http://gacebook.com "？).请记住,能够从命令行使用OAuth承载令牌显然是一个用例持有者令牌倡导者提升.

Answer 5

OAuth 1.0协议(RFC 5849)的安全性依赖于嵌入客户端应用程序中的密钥可以保密的假设.但是,这个假设是天真的.

在OAuth 2.0(RFC 6749)中,这种天真的客户端应用程序称为机密客户端.另一方面,在难以保密密钥的环境中的客户端应用程序被称为公共客户端.见2.1.客户类型详情.

从这个意义上讲,OAuth 1.0仅适用于机密客户端.

" OAuth 2.0和地狱之路 "说OAuth 2.0安全性较低,但OAuth 1.0客户端和OAuth 2.0机密客户端之间的安全级别没有实际差异.OAuth 1.0需要计算签名,但如果已经确保客户端的密钥可以保密,则不会增强安全性.计算签名只是一个繁琐的计算,没有任何实际的安全性增强.我的意思是,相比一个OAuth 2.0客户端连接到了TLS的服务器,只是呈现的简单client_id和client_secret,就不能说是繁琐的计算是在安全性方面更好.

此外,RFC 5849(OAuth 1.0)没有提到有关开放重定向器的任何内容,而RFC 6749(OAuth 2.0)也是如此.也就是说,oauth_callbackOAuth 1.0的参数可以成为安全漏洞.

因此,我认为OAuth 1.0不比OAuth 2.0更安全.

^{[2016年4月14日]除了澄清我的观点}

OAuth 1.0安全性依赖于签名计算.签名是使用秘密密钥,其中秘密密钥为HMAC-SHA1(共享的密钥计算的RFC 5849,3.4.2)或RSA-SHA1的私钥(RFC 5849,3.4.3).知道密钥的任何人都可以计算签名.因此,如果秘密密钥被泄露,则签名计算的复杂性是无意义的,但是它是复杂的.

这意味着OAuth 1.0安全性不依赖于签名计算的复杂性和逻辑,而仅依赖于秘密密钥的机密性.换句话说,OAuth 1.0安全性所需要的只是保密密钥可以保密的条件.这可能听起来很极端,但如果条件已经满足,则签名计算不会增加安全性.

同样,OAuth 2.0 机密客户端也依赖于相同的条件.如果条件已经满足,使用TLS创建安全连接并通过安全连接发送client_id和client_secret授权服务器是否有任何问题？如果两者都依赖于相同的条件,OAuth 1.0和OAuth 2.0机密客户端之间的安全级别是否有很大差异？

我找不到OAuth 1.0责备OAuth 2.0的任何理由.事实很简单:(1)OAuth 1.0仅仅是机密客户端的规范;(2)OAuth 2.0也简化了机密客户端和支持的公共客户端的协议.无论是否熟知,智能手机应用程序都归类为公共客户端(RFC 6749,9),它们受益于OAuth 2.0.

Answer 6

生成令牌后,实际API调用不需要OAuth 2.0签名.它只有一个安全令牌.

OAuth 1.0要求客户端为每个API调用发送两个安全性令牌,并使用它们来生成签名.它要求受保护资源端点可以访问客户端凭据以验证请求.

这里描述了OAuth 1.0和2.0之间的区别以及两者是如何工作的.

Answer 7

OAuth 2显然是浪费时间(来自与其密切相关的人的口中):

https://hueniverse.com/oauth-2-0-and-the-road-to-hell-8eec45921529

他说(编辑为简洁和粗体强调):

...我无法再与OAuth 2.0标准相关联.我辞去了主要作者和编辑的职务,从规范中撤回了我的名字,离开了工作组.从一份文件中删除我的名字,我已经辛苦地工作了三年,并且打了二十多个草稿并不容易.决定继续我已经领导超过五年的努力是令人痛苦的.

...最后,我得出的结论是OAuth 2.0是一个糟糕的协议.WS-*糟糕.我不再希望与它联系起来已经够糟糕了....与OAuth 1.0相比,2.0规范更复杂,更少可互操作,更少有用,更不完整,最重要的是,安全性更低.

要明确的是,对Web安全性有深刻理解的开发人员手中的OAuth 2.0可能会带来安全的实现.然而,在大多数开发人员手中 - 正如过去两年的经验 - 2.0可能会产生不安全的实现.

Answer 8

如果您需要一些高级说明，则需要阅读两个规范：

https://oauth.net/core/1.0a/

https://oauth.net/2/

如果您需要清楚地说明流量差异，则可以为您提供帮助：

OAuth 1.0流程

1. 客户端应用程序向提供商（例如Twitter）注册。
2. Twitter为客户提供了该应用程序独有的“消费者秘密”。
3. 客户端应用使用其独特的“消费者秘密”对所有OAuth请求进行签名。
4. 如果任何OAuth请求格式错误，数据丢失或签名不正确，则该请求将被拒绝。

OAuth 2.0流程

1. 客户端应用程序向提供商（例如Twitter）注册。
2. Twitter为客户端提供了该应用程序独有的“客户端机密”。
3. 客户端应用程序包括 “客户端机密”，每个请求通常都作为http标头。
4. 如果任何OAuth请求格式错误，数据丢失或包含错误的机密，则该请求将被拒绝。

来源：https : //codiscope.com/oauth-2-0-vs-oauth-1-0/

Answer 9

OAuth 2.0承诺通过以下方式简化操作:

1. 生成令牌所需的所有通信都需要SSL.这大大降低了复杂性,因为不再需要那些复杂的签名.
2. 生成令牌后,实际API调用不需要签名 - 此处强烈建议使用SSL.
3. 生成令牌后,OAuth 1.0要求客户端在每次API调用时发送两个安全令牌,并使用它们生成签名.OAuth 2.0只有一个安全令牌,不需要签名.
4. 清楚地指定协议的哪些部分由"资源所有者"实现,"资源所有者"是实现API的实际服务器,以及哪些部分可以由单独的"授权服务器"实现.这将使Apigee等产品更容易为现有API提供OAuth 2.0支持.

资料来源:http://blog.apigee.com/detail/oauth_differences