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

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

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/

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