用非常简单的术语来说，有人可以解释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 Access令牌可以存储一年或更长时间（Twitter永远不会让它们过期）。 OAuth 2.0具有刷新令牌的概念。虽然我不完全确定这些是什么，但我的猜测是你的访问令牌可以是短暂的（即基于会话），而你的刷新令牌可以是“生命时间”。您将使用刷新令牌获取新的访问令牌，而不是让用户重新授权您的应用程序。
最后，OAuth 2.0旨在将负责处理OAuth请求的服务器与处理用户授权的服务器之间的角色清晰分离。有关详细信息，请参阅上述文章。
从安全的角度来看，我会选择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对于大规模更好，但是如果你正在运行一个主要的操作，你可能会在现场安排一些安全专家来为你解决这个问题。“
我在这里看到很好的答案，但我想念的是一些图表，因为我必须使用Spring Framework，我遇到了their explanation。
我发现以下图表非常有用。它们说明了OAuth2和OAuth1之间的通信差异。
以前的解释都是过于详细和复杂的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 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）在RFC 6749（OAuth 2.0）的同时没有提及有关open redirectors的任何内容。也就是说，OAuth 1.0的oauth_callback参数可以成为安全漏洞。
因此，我认为OAuth 1.0不比OAuth 2.0更安全。
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。
生成令牌后，实际API调用不需要OAuth 2.0签名。它只有一个安全令牌。
OAuth 1.0要求客户端为每个API调用发送两个安全性令牌，并使用它们来生成签名。它要求受保护资源端点可以访问客户端凭据以验证请求。
Here描述了OAuth 1.0和2.0之间的区别以及它们是如何工作的。
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可能会产生不安全的实现。
如果您需要一些高级解释，您需要阅读两个规范：
如果您需要清楚地解释流量差异，这可以帮助您：
OAuth 1.0流程
OAuth 2.0流程
OAuth 2.0承诺通过以下方式简化操作：