What's the difference? OAuth 1.0 vs OAuth 2.0

What is the difference between OAuth 1.0 and OAuth 2.0?

OAuth 1.0 presented the Delegation with a digital signature-based system in December 2007. It's been strong and resilient. Major players had started adopting it. Google launched support for OAuth 1.0 in 2008. In 2010 Twitter had required all third-party apps to use their implementation of OAuth 1.0.

OAuth 1.0 did require crypto-implementation and crypto-interoperability. Although safe, implementing this has been a challenge for many developers.

Then, in October 2012, OAuth 2.0 came. OAuth 2.0 is much easier to implement with its crypto underpinnings than OAuth 1.0, the new version includes several security-level vulnerabilities.

Perhaps the use of OAuth 1.0 as a client-side implementer is no longer feasible. For example, in April 2012, Google moved off OAuth 1.0 and no longer allows OAuth 1.0 to be used. Nonetheless, Twitter also fully supports OAuth 1.0. OAuth 1.0 can also be excluded from the OAuth 1.0 scheme.

OAuth 2.0 signatures are not required for the actual API calls once the token has been generated. It has only one security token. OAuth 1.0 requires client to send two security tokens for each API call, and use both to generate the signature.

OAuth 1.0

1. Transport independent: Under HTTPS / TLS security is not delegated.
2. Digital signatures: The digital signatures are used to prove a message's integrity and authenticity. Digital signatures may guarantee that a certain message has been sent from a particular source, and that the message and signature have not been altered in any way. It can't be manipulated or copied to another source, but implementations on the client side can be particularly complex.
3. Each of the messages is individually cryptographically signed.
4. OAuth1.0 Basic signature workflow:
   • Client application registers with provider, such as Google/Facebook.
   • Google/Facebook provides client with a "consumer secret" unique to that application.
   • Client app signs all OAuth requests to Google/Facebook with its unique "consumer secret".
   • The request will be denied if any of the OAuth request is malformed, missing data or signed incorrectly.

OAuth 2.0

1. Transport-dependent: HTTPS / TLS is delegated to most security defenses. Improper TLS configuration, failure to validate a certificate properly, or vulnerabilities in the underlying library can result in a man-in - the-middle (MitM) attack, which could compromise all OAuth communications.
2. Easier and Flexible to work: OAuth 2.0 is much more flexible but much harder to securely develop. OAuth 1.0 support only web workflows, but OAuth 2.0 supports even non-web clients as well.
3. Based on bearer tokens: This is easy to integrate, but not very secure. Bearer tokens do not provide mechanisms of internal security. They can be copied or stolen but can be introduced more easily.
4. Improved segregation of tasks: The OAuth 2.0 will decouple the handling of resource requests and the handling of user authorization.
5. OAuth 2.0 Basic signature workflow:
   • Client application registers with provider, such as Google/Facebook.
   • Google provides client with a "client secret" unique to that application.
   • Client application includes "client secret" with every request.
   • The request will be denied if any of the OAuth request is malformed, missing data or contains the wrong code.

To know more about OAuth2.0, visit OAuth2.0 Tutorial