OAuth 2与OAuth 1有何不同？

Question

简单来说，有人可以解释OAuth 2和OAuth 1之间的区别吗？

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

Answer 1

Eran Hammer-Lahav在解释他的文章Introducing 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访问令牌可以存储一年或更长时间（Twitter永远不会让它们过期）。 OAuth 2.0具有刷新令牌的概念。虽然我不完全确定这些是什么，但我的猜测是你的访问令牌可以是短暂的（即基于会话），而你的刷新令牌可以是“生命时间”。您将使用刷新令牌获取新的访问令牌，而不是让用户重新授权您的应用程序。

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

Answer 2

我在这里看到了很好的答案，但我想念的是一些图表，因为我必须使用Spring Framework，我遇到了their explanation。

我发现以下图表非常有用。它们说明了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：

one bleak article

and a more technical one

请注意，这些来自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）中，这种天真的客户端应用程序称为机密客户端。另一方面，在难以保密密钥的环境中的客户端应用程序称为 public 客户端。有关详细信息，请参阅2.1. Client Types。

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

＆＃34; OAuth 2.0 and the Road to Hell＆＃34;表示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）的同时未提及open redirectors的任何内容。也就是说，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_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调用发送两个安全令牌，并使用它们来生成签名。它要求受保护资源端点可以访问客户端凭据以验证请求。

Here描述了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   规范更复杂，互操作性更低，实用性更低，更多   不完整，最重要的是，安全性较低。

     

要明确，开发人员手中的OAuth 2.0很深   对网络安全的理解可能会带来安全感   实现。然而，在大多数开发人员手中 - 一如既往   过去两年的经验 - 2.0很可能产生   不安全的实施。

Answer 8

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

Answer 9

如果您需要一些高级解释，则需要阅读这两个规范：

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

https://oauth.net/2/

如果您需要清楚地解释流量差异，这可以帮助您：

OAuth 1.0流程

1. 客户端应用程序向提供商注册，例如Twitter。
2. Twitter为客户提供该应用程序独有的“消费者秘密”。
3. 客户端应用签署所有对Twitter 的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 10

从安全角度来看，我选择OAuth 1.请参阅OAuth 2.0 and the road to hell

引用该链接： ＆＃34;如果您当前正在使用1.0，请忽略2.0。它没有提供超过1.0的实际价值（我猜你的客户开发人员现在已经找到了1.0个签名）。

如果您是这个领域的新手，并认为自己是安全专家，请在仔细检查其功能后使用2.0。如果您不是专家，请使用1.0或复制您信任的提供商的2.0实现以使其正确（Facebook的API文档是一个很好的起点）。 2.0对于大规模更好，但是如果你正在运行一个主要的操作，你可能会在现场安排一些安全专家来为你解决这个问题。＆＃34;