OAuth 2与OAuth 1有什么不同？
用非常简单的术语，有人可以解释OAuth 2和OAuth 1之间的区别吗？
OAuth 1现在是否过时了？ 应该实现OAuth 2吗？ 我没有看到许多OAuth 2的实现; 大多数仍在使用OAuth 1，这让我怀疑OAuth 2是否可以使用。 是吗？
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请求的服务器与处理用户授权的服务器之间的角色完全分离。 有关这方面的更多信息详见上述文章。
我在这里看到了很好的答案，但是我错过了一些图表，因为我必须使用Spring框架，所以我遇到了他们的解释。
我发现下面的图非常有用。 它们说明了使用OAuth2和OAuth1的各方之间的沟通差异。
OAuth 2
OAuth 1
以前的解释都是过于详细和复杂的国际海事组织。 简而言之，OAuth 2将安全委托给HTTPS协议。 OAuth 1不需要这个，因此有其他方法来处理各种攻击。 这些方法要求应用程序参与某些复杂且难以实施的安全协议。 因此，仅仅依靠HTTPS进行安全性更简单，这样应用程序开发人员就不用担心了。
至于你的其他问题，答案取决于。 有些服务不想要求使用HTTPS，在OAuth 2之前开发，或者有其他一些要求可能会阻止他们使用OAuth 2.另外，关于OAuth 2协议本身的争论很多。 正如你所看到的，Facebook，Google和其他几个实施的协议版本略有不同。 所以有些人坚持使用OAuth 1，因为它在不同的平台上更加统一。 最近，OAuth 2协议已经完成，但我们尚未看到如何采用它。
链接地址: http://www.djcxy.com/p/22337.html