OAuth 2 与 OAuth 1 有何不同？
用非常简单的术语，有人可以解释 OAuth 2 和 OAuth 1 之间的区别吗？
OAuth 1 现在过时了吗？我们应该实施 OAuth 2 吗？我没有看到很多 OAuth 2 的实现。大多数人仍在使用 OAuth 1，这让我怀疑 OAuth 2 是否可以使用。是吗？
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 请求的服务器和处理用户授权的服务器之间有一个清晰的角色分离。有关这方面的更多信息，请参阅上述文章。
我在这里看到了很好的答案，但我错过了一些图表，因为我必须使用 Spring Framework，所以我遇到了 their explanation。
我发现下面的图表非常有用。它们说明了使用 OAuth2 和 OAuth1 的各方之间的通信差异。
认证 2
https://i.stack.imgur.com/Xn4c0.png
OAuth 1
https://i.stack.imgur.com/UmvA7.png
OAuth 2 的第 2 步和 OAuth 1 的第 4 步。
前面的解释都是过于详细和复杂的IMO。简而言之，OAuth 2 将安全性委托给 HTTPS 协议。 OAuth 1 不需要这样做，因此有替代方法来处理各种攻击。这些方法要求应用程序参与某些复杂且难以实施的安全协议。因此，仅依靠 HTTPS 进行安全性比较简单，应用程序开发人员无需担心。
至于你的其他问题，答案取决于。有些服务不想要求使用 HTTPS，它们是在 OAuth 2 之前开发的，或者有一些其他要求可能会阻止它们使用 OAuth 2。此外，关于 OAuth 2 协议本身存在很多争论。如您所见，Facebook、Google 和其他一些公司各自实施的协议版本略有不同。所以有些人坚持使用 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 1.0 协议 (RFC 5849) 的安全性依赖于嵌入在客户端应用程序中的密钥可以保密的假设。然而，这种假设是幼稚的。
在 OAuth 2.0 (RFC 6749) 中，这种天真的客户端应用程序称为 机密 客户端。另一方面，在难以保密密钥的环境中的客户端应用程序称为公共客户端。详见2.1. Client Types。
从这个意义上说，OAuth 1.0 是仅适用于机密客户端的规范。
“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_id 和 client_secret 的简单性，不能说繁琐的计算在安全性方面更好。
此外，RFC 5849 (OAuth 1.0) 没有提及 open redirectors，而 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 简化了机密客户端的协议并支持 public 客户端。不管它是否广为人知，智能手机应用程序都被归类为公共客户端 (RFC 6749, 9)，它们受益于 OAuth 2.0。
生成令牌后，实际 API 调用不需要 OAuth 2.0 签名。它只有一个安全令牌。
OAuth 1.0 要求客户端为每个 API 调用发送两个安全令牌，并使用两者来生成签名。它要求受保护的资源端点可以访问客户端凭据以验证请求。
Here 描述了 OAuth 1.0 和 2.0 之间的区别以及两者的工作方式。
OAuth 2 显然是在浪费时间（从一个参与其中的人的口中）：
https://gist.github.com/nckroy/dd2d4dfc86f7d13045ad715377b6a48f
他说（为简洁而编辑，为强调而加粗）：
...我无法再与 OAuth 2.0 标准相关联。我辞去了主要作者和编辑的职务，从规范中撤消了我的名字，并离开了工作组。从一份我辛苦工作了三年、两打草稿的文件中删除我的名字并不容易。决定从我领导了五年多的努力中继续前进是痛苦的。 ...最后，我得出结论，OAuth 2.0 是一个糟糕的协议。 WS-* 不好。这已经够糟糕了，我不想再与它联系在一起了。 ...与 OAuth 1.0 相比，2.0 规范更复杂，互操作性更低，用处更少，更不完整，最重要的是，安全性更低。需要明确的是，OAuth 2.0 掌握在对 Web 安全有深入了解的开发人员手中，很可能会是一个安全的实现。然而，在大多数开发人员手中——就像过去两年的经验一样——2.0 可能会产生不安全的实现。
如果您需要一些高级解释，则需要阅读这两个规范：
正如您将看到的，存在一些概念上的差异。
如果您需要使用 oauth1 或 oauth2 使用或发布某些服务，这里我将向您展示一个技术差异：
OAuth 1.0 流程
客户端应用程序向提供商注册，例如 Twitter。 Twitter 为客户提供该应用程序独有的“消费者秘密”。客户端应用程序使用其独特的“消费者秘密”签署所有对 Twitter 的 OAuth 请求。如果任何 OAuth 请求格式不正确、缺少数据或签名不正确，该请求将被拒绝。
OAuth 2.0 流程
客户端应用程序向提供商注册，例如 Twitter。 Twitter 为客户端提供该应用程序独有的“客户端密码”。客户端应用程序包含“客户端密码”，每个请求通常作为 http 标头。如果任何 OAuth 请求格式错误、缺少数据或包含错误的机密，则该请求将被拒绝。
资料来源：
https://www.synopsys.com/blogs/software-security/oauth-2-0-vs-oauth-1-0/
OAuth 2.0 承诺通过以下方式简化事情：
生成令牌所需的所有通信都需要 SSL。这大大降低了复杂性，因为不再需要那些复杂的签名。生成令牌后，实际 API 调用不需要签名——这里也强烈建议使用 SSL。生成令牌后，OAuth 1.0 要求客户端在每次 API 调用时发送两个安全令牌，并使用两者来生成签名。 OAuth 2.0 只有一个安全令牌，不需要签名。明确规定了协议的哪些部分由“资源所有者”实现，“资源所有者”是实现 API 的实际服务器，哪些部分可以由单独的“授权服务器”实现。这将使 Apigee 等产品更容易为现有 API 提供 OAuth 2.0 支持。
来源：http://blog.apigee.com/detail/oauth_differences
从安全的角度来看，我会选择 OAuth 1。请参阅 OAuth 2.0 and the road to hell。
引用该链接：
“如果您当前成功使用 1.0，请忽略 2.0。它没有提供超过 1.0 的实际价值（我猜您的客户端开发人员现在已经弄清楚了 1.0 签名）。如果您是这个领域的新手，并认为自己是安全的专家，请在仔细检查其功能后使用 2.0。如果您不是专家，请使用 1.0 或复制您信任的提供商的 2.0 实现以使其正确（Facebook 的 API 文档是一个很好的起点）。2.0 更好对于大规模，但如果您正在运行一项大型操作，您可能会有一些安全专家在现场为您解决所有问题。”
