OAuth 2和OAuth 1有什么不同?

简单来说，有人能解释一下OAuth 2和OAuth 1之间的区别吗?

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

268275 次浏览
小开

Eran Hammer-Lahav在他的文章介绍OAuth 2.0中很好地解释了大部分差异。总结一下，这是关键的区别:

这是对非基于浏览器的客户端应用程序的OAuth的主要批评。例如，在OAuth 1.0中，桌面应用程序或移动电话应用程序必须引导用户打开浏览器到所需的服务，使用该服务进行身份验证，并将令牌从服务复制回应用程序。这里的主要批评是针对用户体验。有了OAuth 2.0，应用程序现在有了获取用户授权的新方法。

这让人想起了旧的Twitter Auth API，它不需要应用程序HMAC哈希令牌和请求字符串。使用OAuth 2.0，应用程序可以仅使用通过HTTPS发出的令牌发出请求。

没有更多特殊的解析、排序或编码。

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

关于这方面的更多信息在前面提到的文章中有详细介绍。

小开

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

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

在这里描述了OAuth 1.0和2.0之间的区别以及两者的工作方式。

小开

在我看来，之前的解释都过于详细和复杂。简单地说，OAuth 2将安全性委托给HTTPS协议。OAuth 1不需要这样做，因此有替代方法来处理各种攻击。这些方法要求应用程序参与某些复杂且难以实现的安全协议。因此，仅仅依靠HTTPS来获得安全性会更简单，因此应用程序开发人员不需要担心它。

至于你的其他问题，看情况而定。有些服务不想要求使用HTTPS，它们是在OAuth 2之前开发的，或者有其他一些要求可能会阻止它们使用OAuth 2。此外，关于OAuth 2协议本身也有很多争论。如您所见，Facebook、谷歌和其他一些网站都实现了略有不同的协议版本。所以有些人坚持使用OAuth 1，因为它在不同的平台上更加统一。最近，OAuth 2协议已经最终确定，但我们还没有看到它将如何被采用。

小开

注意使用Oauth 2存在严重的安全问题:

一篇惨淡的文章

和一个更技术性的

注意这些都来自Oauth 2的主要作者。

重点:

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

  • 在某种意义上SSL是不安全的，因为服务器不验证连接，公共客户端库很容易忽略故障。

    SSL/TLS的问题是，当您无法在客户端验证证书时，连接仍然可以工作。任何时候忽略错误都会导致成功，开发人员都会这样做。服务器无法强制执行证书验证，即使可以，攻击者也肯定不会。

    李< /引用> < / >

  • 你可以忽略你所有的安全，这在OAuth 1.0中很难做到:

    第二个常见的潜在问题是拼写错误。当省略一个字符(' https '中的' s ')会使令牌的整个安全性失效时，您认为这是一个正确的设计吗?或者可能将请求(通过有效且经过验证的SSL/TLS连接)发送到错误的目的地(例如“http://gacebook.com”?)请记住，能够从命令行使用OAuth承载令牌显然是承载令牌倡导者提倡的用例。

    李< /引用> < / >
小开

OAuth 2.0承诺在以下方面简化事情:

  1. 生成令牌所需的所有通信都需要SSL。这大大降低了复杂性，因为不再需要那些复杂的签名。
  2. 一旦生成了令牌，实际的API调用就不需要签名了——这里也强烈建议使用SSL。
  3. 令牌生成后，OAuth 1.0要求客户端在每个API调用上发送两个安全令牌，并使用这两个安全令牌来生成签名。OAuth 2.0只有一个安全令牌，不需要签名。
  4. 它明确指定了协议的哪些部分由“资源所有者”实现，即实现API的实际服务器，而哪些部分可以由单独的“授权服务器”实现。这将使Apigee等产品更容易为现有api提供OAuth 2.0支持。

来源:# EYZ0

小开

OAuth 2显然是在浪费时间(来自一个参与其中的人):

https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a48f

他说(为简洁起见，加粗了):

< p >…我再也不能这样了 与OAuth 2.0标准相关。我辞去了领导的职务 作者和编辑，从规范中撤回我的名字，然后离开 工作组。把我的名字从我的文件中删除 辛辛苦苦写了三年，写了二十多稿 这并不容易。决定从我领导的努力中走出来 五年是痛苦的。< p> < p >…最后，我得出的结论是OAuth 2.0不好 协议。WS - *坏。我不想再活下去已经够糟了 与之关联. ...与OAuth 1.0相比，2.0 规范更复杂，互操作性更差，实用性更差

要清楚的是，<强大的>OAuth 2.0在开发人员的手与深 了解网络安全就有可能获得安全 实现。然而，在大多数开发者的手中——就像过去一样 过去两年的经验- 2.0可能会产生 不安全的实现。< /强> < / p >
小开

从安全的角度来看，我选择OAuth 1。看到# EYZ0。

引用这个链接:

如果你目前正在成功地使用1.0，请忽略2.0。它在1.0以上没有任何实际价值(我猜您的客户端开发人员现在已经找到了1.0签名)。

如果您是这个领域的新手，并且认为自己是安全专家，那么在仔细研究了2.0的特性之后再使用它。如果您不是专家，可以使用1.0或复制您信任的提供商的2.0实现(Facebook的API文档是一个很好的开始)。2.0更适合大规模使用，但如果您正在运行大型操作，您可能会有一些安全专家在现场为您解决所有问题。”

小开

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

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

OAuth 2

enter image description here

OAuth 1

enter image description here

小开

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

在OAuth 2.0 (RFC 6749)中，这样一个简单的客户机应用程序被称为保密客户机。另一方面，在难以保证密钥机密性的环境中的客户机应用程序称为公共客户机。详见2.1. 客户端类型。

从这个意义上说，OAuth 1.0是一个仅针对机密客户机的规范。

“# EYZ2"说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 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。

小开

如果你需要一些高级解释，你需要阅读这两个规范:

< a href = " https://oauth.net/core/1.0a/ " rel = " noreferrer > https://oauth.net/core/1.0a/ < / >

< a href = " https://oauth.net/2/ " rel = " noreferrer > https://oauth.net/2/ < / >

正如您将看到的，这里有几个概念上的差异。

在这里，如果你需要使用oauth1或oauth2来消费或发布一些服务，我将向你展示技术的区别:

OAuth 1.0流程

  1. 客户端应用程序向提供者注册，比如Twitter。
  2. Twitter为客户端提供了该应用程序独有的“消费者秘密”。
  3. 客户端应用程序迹象所有OAuth请求推特与其独特的“消费者的秘密。”
  4. 如果任何OAuth请求格式不正确、缺少数据或签名不正确，该请求将被拒绝。

OAuth 2.0流程

  1. 客户端应用程序向提供者注册，比如Twitter。
  2. Twitter为客户端提供了该应用程序独有的“客户端秘密”。
  3. 客户端应用程序包括 “客户的秘密”和每一个请求通常作为http头。
  4. 如果任何OAuth请求格式不正确、缺少数据或包含错误的秘密，该请求将被拒绝。

来源:


提交答案