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

SSL is required for all the communications required to generate the token. This is a huge decrease in complexity because those complex signatures are no longer required. Signatures are not required for the actual API calls once the token has been generated -- SSL is also strongly recommended here. Once the token was generated, OAuth 1.0 required that the client send two security tokens on every API call, and use both to generate the signature. OAuth 2.0 has only one security token, and no signature is required. It is clearly specified which parts of the protocol are implemented by the "resource owner," which is the actual server that implements the API, and which parts may be implemented by a separate "authorization server." That will make it easier for products like Apigee to offer OAuth 2.0 support to existing APIs.

来源:http://blog.apigee.com/detail/oauth_differences

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

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

OAuth 2

OAuth 1

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

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

https://oauth.net/2/

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

如果你需要使用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将安全性委托给HTTPS协议。OAuth 1不需要这样做，因此有替代方法来处理各种攻击。这些方法要求应用程序参与某些复杂且难以实现的安全协议。因此，仅仅依靠HTTPS来获得安全性会更简单，因此应用程序开发人员不需要担心它。

As to your other questions, the answer depends. Some services dont want to require the use of HTTPS, were developed before OAuth 2, or have some other requirement which may prevent them from using OAuth 2. Furthermore, there has been a lot of debate about the OAuth 2 protocol itself. As you can see, Facebook, Google, and a few others each have slightly varying versions of the protocols implemented. So some people stick with OAuth 1 because it is more uniform across the different platforms. Recently, the OAuth 2 protocol has been finalized but we have yet to see how its adoption will take.

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

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

下面介绍OAuth 1.0和2.0之间的区别以及两者的工作方式。

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

在OAuth 2.0 (RFC 6749)中，这样的简单客户机应用程序称为机密客户机。另一方面，在难以对密钥进行保密的环境中的客户端应用程序称为公共客户端。见2.1。客户类型的详细信息。

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

"OAuth 2.0 and the Road to Hell" says that OAuth 2.0 is less secure, but there is no practical difference in security level between OAuth 1.0 clients and OAuth 2.0 confidential clients. OAuth 1.0 requires to compute signature, but it does not enhance security if it is already assured that a secret key on the client side can be kept confidential. Computing signature is just a cumbersome calculation without any practical security enhancement. I mean, compared to the simplicity that an OAuth 2.0 client connects to a server over TLS and just presents client_id and client_secret, it cannot be said that the cumbersome calculation is better in terms of security.

此外，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。