oauth-2.0 oauth2流程 - OAuth 2与OAuth 1有什么不同?




oauth2区别 oauth2.0比oauth1.0安全在哪里 (10)

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

OAuth 1现在是否过时了? 应该实现OAuth 2吗? 我没有看到许多OAuth 2的实现; 大多数仍在使用OAuth 1,这让我怀疑OAuth 2是否可以使用。 是吗?


Answers

我在这里看到了很好的答案,但是我错过了一些图表,因为我必须使用Spring框架,所以我遇到了他们的解释

我发现下面的图非常有用。 它们说明了使用OAuth2和OAuth1的各方之间的沟通差异。

OAuth 2

OAuth 1


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_differenceshttp://blog.apigee.com/detail/oauth_differences


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

更多OAuth Flows可以更好地支持基于非浏览器的应用程序。 这是来自非基于浏览器的客户端应用程序对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访问令牌可以存储一年或更长时间(Twitter永不让它们过期)。 OAuth 2.0具有刷新令牌的概念。 虽然我不完全确定这些是什么,但我的猜测是,您的访问令牌可以是短暂的(即基于会话),而刷新令牌可以是“生命期”。 您将使用刷新令牌来获取新的访问令牌,而不是让用户重新授权您的应用程序。

最后,OAuth 2.0旨在将负责处理OAuth请求的服务器与处理用户授权的服务器之间的角色完全分离。 有关这方面的更多信息详见上述文章。


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

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

从这个意义上讲,OAuth 1.0只是一个针对机密客户的规范。

hueniverse.com/2012/07/oauth-2-0-and-the-road-to-hell ”说OAuth 2.0不太安全,但OAuth 1.0客户端和OAuth 2.0机密客户端之间的安全级别没有实际差异。 OAuth 1.0需要计算签名,但如果已确信客户端的密钥可以保密,则它不会增强安全性。 计算签名只是一个繁琐的计算,没有任何实际的安全增强。 我的意思是,与OAuth 2.0客户端通过TLS连接到服务器并提供client_idclient_secret的简单性相比,不能说繁琐的计算在安全性方面更好。

另外,RFC 5849(OAuth 1.0)在RFC 6749(OAuth 2.0)中没有提及任何有关开放重定向器的内容。 也就是说,OAuth 1.0的oauth_callback参数可能会成为安全漏洞。

因此,我不认为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_idclient_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。


从安全角度来看,我会选择OAuth 1.请参阅OAuth 2.0和通向地狱的道路

引用该链接:“如果你目前正在使用1.0版本,忽略2.0版本,它没有提供超过1.0的实际价值(我猜你的客户端开发人员现在已经计算出1.0签名)。

如果您对这个空间不熟悉,并认为自己是安全专家,请仔细检查其功能后再使用2.0。 如果您不是专家,请使用1.0或复制您信任的提供商的2.0实施方案(Facebook的API文档是开始的好地方)。 2.0对于大规模应用来说更好,但如果您正在进行大规模的操作,那么您可能会在现场安排一些安全专家为您解决问题。“


OAuth 2显然是浪费时间(从大量参与其中的人的口中):

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

他说(为简洁起见编辑并强调):

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

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

要明确的是, 开发人员对OAuth 2.0的深入理解可能会导致安全实施。 然而,在大多数开发人员的手中 - 正如过去两年的经验 - 2.0可能会产生不安全的实现。


如果您想查看OAuth的简明说明和详细流程(使用图表),可以查看http://oauthbible.com


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

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

Here描述了OAuth 1.0和2.0之间的区别以及两者如何工作。


以前的解释都是过于详细和复杂的国际海事组织。 简而言之,OAuth 2将安全委托给HTTPS协议。 OAuth 1不需要这个,因此有其他方法来处理各种攻击。 这些方法要求应用程序参与某些复杂且难以实施的安全协议。 因此,仅仅依靠HTTPS进行安全性更简单,这样应用程序开发人员就不用担心了。

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


根据我读到的内容,这是如何工作的:

问题中概述的一般流程是正确的。 在步骤2中,用户X被认证,并且还授权站点A访问用户X在站点B上的信息。在步骤4中,站点将其秘密传递回站点B,自我认证以及授权码,指示什么它要求(用户X的访问令牌)。

总体而言,OAuth 2实际上是一个非常简单的安全模型,加密永远不会直接发挥作用。 相反,秘密和安全令牌本质上都是密码,并且整个事情仅由https连接的安全性来保护。

OAuth 2没有针对安全令牌或秘密的重放攻击提供保护。 相反,它完全依赖站点B负责这些项目,并且不让他们离开,并且在传输时通过https发送(https将保护URL参数)。

授权代码步骤的目的很简单,授权代码本身并不特别敏感。 当为用户X的访问令牌询问站点B时,它为站点A的用户X的访问令牌提供公共标识符。 只要用户X在B站点上的用户标识不起作用,因为可能有许多未完成的访问令牌同时等待分发到不同的站点。





oauth oauth-2.0 authorization