What’s the difference? OAuth 1.0 vs OAuth 2.0

“Which version of OAuth is right for me?” You might expect the answer to this question to be “The latest, obviously.” But this is not necessarily the case. The changes that took place between OAuth 1.0 and OAuth 2.0 actually changed the nature of OAuth significantly enough that the two versions actually meet different needs, based on what you’re trying to accomplish. Why is that?

A little history around OAuth 1.0 and OAuth 2.0

In December 2007, OAuth 1.0 addressed delegation with a framework based on digital signatures. It was secure and it was strong. Major players began to adopt it. Google began OAuth 1.0 support in 2008. By 2010, Twitter forced all third-party apps to use their OAuth 1.0 implementation.

However, OAuth 1.0 required crypto-implementation and crypto-interoperability. While secure, it was a challenge for many developers to implement.

Then came OAuth 2.0 in October 2012.

Building a secure OAuth solution is no easy challenge. Large enterprises joined the OAuth standard body and influenced it in many ways. While OAuth 2.0 is much easier to implement than OAuth 1.0 with its crypto underpinnings, the new version contains many compromises at the security level.

However, support for non-browser implementations and a clear separation of resource delivery and authorization helped make the new standard more usable for large enterprises and more.

So how do I choose?

In many cases, it is no longer feasible to use OAuth 1.0 as a client-side implementer. For example, Google moved away from OAuth 1.0 in April 2012, and no longer permits the use of OAuth 1.0. However, Twitter still fully supports OAuth 1.0.

It is very rare to see new authorization server implementations of OAuth 1.0. However, you can still consider OAuth 1.0 if your resource provider still supports it (and has committed to continue supporting it), you have developers with good experience in cryptography, and you have good key management capabilities.

These are a lot of “ifs,” and OAuth 2.0 is almost always the right choice today. If your desire is to use OAuth with proper cryptography, the trend is more and more to use OAuth 2.0 with cryptographic extensions.

Still wondering what to do? Compare the security properties of both versions and decide which is right for your implementation.

OAuth 1.0

• Transport-independent. Security is not delegated to HTTPS/TLS.
• Founded in cryptography, especially digital signatures. Digital signatures are used to prove the integrity and authenticity of a message. Digital signatures can ensure that a certain message was sent from a specific source and that the message and signature were not tampered with in any way. A signed message is tied to its origin. It cannot be tampered with or copied to another source, but client-side implementations can be especially complex.
• Messages are each individually cryptographically signed. If a single message within the communication is constructed or signed improperly, the entire transaction will be invalidated
• Basic signature workflow.

1. Client application registers with provider, such as Twitter.
2. Twitter provides client with a “consumer secret” unique to that application.
3. Client app signs all OAuth requests to Twitter with its unique “consumer secret.”
4. If any of the OAuth request is malformed, missing data, or signed improperly, the request will be rejected.

Note: Some use the OAuth 1.0 scope parameter to carry authorization/entitlement in addition to the token; that can be a useful architecture consideration.