Note there are serious security arguments against using Oauth 2:
Note these are coming from Oauth 2's lead author.
Key points:
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.