在我看来，之前的解释都过于详细和复杂。简单地说，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.

注意使用Oauth 2存在严重的安全问题:

一篇令人沮丧的文章

一个更专业的问题

注意这些都来自Oauth 2的主要作者。

重点:

Oauth 2 offers no security on top of SSL while Oauth 1 is transport-independent. in a sense SSL isn't secure in that the server does not verify the connection and the common client libraries make it easy to ignore failures. The problem with SSL/TLS, is that when you fail to verify the certificate on the client side, the connection still works. Any time ignoring an error leads to success, developers are going to do just that. The server has no way of enforcing certificate verification, and even if it could, an attacker will surely not. you can fat-finger away all of your security, which is much harder to do in OAuth 1.0: The second common potential problem are typos. Would you consider it a proper design when omitting one character (the ‘s’ in ‘https’) voids the entire security of the token? Or perhaps sending the request (over a valid and verified SSL/TLS connection) to the wrong destination (say ‘http://gacebook.com’?). Remember, being able to use OAuth bearer tokens from the command line was clearly a use case bearer tokens advocates promoted.

在我看来，之前的解释都过于详细和复杂。简单地说，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.

从安全的角度来看，我选择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.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