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

More OAuth Flows to allow better support for non-browser based applications. This is a main criticism against OAuth from client applications that were not browser based. For example, in OAuth 1.0, desktop applications or mobile phone applications had to direct the user to open their browser to the desired service, authenticate with the service, and copy the token from the service back to the application. The main criticism here is against the user experience. With OAuth 2.0, there are now new ways for an application to get authorization for a user.

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请求的服务器和处理用户授权的服务器之间有一个清晰的角色分离。在前面提到的文章中有详细的信息。

从安全的角度来看，我选择OAuth 1。参见OAuth 2.0和地狱之路。

引用这个链接:

"If you are currently using 1.0 successfully, ignore 2.0. It offers no real value over 1.0 (I’m guessing your client developers have already figured out 1.0 signatures by now). If you are new to this space, and consider yourself a security expert, use 2.0 after careful examination of its features. If you are not an expert, either use 1.0 or copy the 2.0 implementation of a provider you trust to get it right (Facebook’s API documents are a good place to start). 2.0 is better for large scale, but if you are running a major operation, you probably have some security experts on site to figure it all out for you."

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

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

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

...I can no longer be associated with the OAuth 2.0 standard. I resigned my role as lead author and editor, withdraw my name from the specification, and left the working group. Removing my name from a document I have painstakingly labored over for three years and over two dozen drafts was not easy. Deciding to move on from an effort I have led for over five years was agonizing. ...At the end, I reached the conclusion that OAuth 2.0 is a bad protocol. WS-* bad. It is bad enough that I no longer want to be associated with it. ...When compared with OAuth 1.0, the 2.0 specification is more complex, less interoperable, less useful, more incomplete, and most importantly, less secure. To be clear, OAuth 2.0 at the hand of a developer with deep understanding of web security will likely result is a secure implementation. However, at the hands of most developers – as has been the experience from the past two years – 2.0 is likely to produce insecure implementations.

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

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

OAuth 2

OAuth 1

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。

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

More OAuth Flows to allow better support for non-browser based applications. This is a main criticism against OAuth from client applications that were not browser based. For example, in OAuth 1.0, desktop applications or mobile phone applications had to direct the user to open their browser to the desired service, authenticate with the service, and copy the token from the service back to the application. The main criticism here is against the user experience. With OAuth 2.0, there are now new ways for an application to get authorization for a user.

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请求的服务器和处理用户授权的服务器之间有一个清晰的角色分离。在前面提到的文章中有详细的信息。