Software Integrity

 

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.

OAuth 2.0

  • Transport-Dependent. Most security defenses are delegated to HTTPS/TLS. A typo, an improper TLS configuration, a failure to properly validate a certificate, or vulnerabilities in an underlying library can lead to a man-in-the-middle (MiTM) attack, compromising all OAuth communications.
  • Centered around bearer tokens. These are easy for integration but not great for security. Bearer tokens do not provide internal security mechanisms. They can be copied or stolen but are easier to implement.
  • Much easier to work with. OAuth 2.0 is much more usable, but much more difficult to build securely.
  • Much more flexible. OAuth 1.0 only handled web workflows, but OAuth 2.0 considers non-web clients as well.
  • Better separation of duties. Handling resource requests and handling user authorization can be decoupled in OAuth 2.0.
  • Basic Signature Workflow.
  1. Client application registers with provider, such as Twitter.
  2. Twitter provides client with a “client secret” unique to that application.
  3. Client application includes “client secret” with every request.
  4. If any of the OAuth request is malformed, missing data, or contains the wrong secret, the request will be rejected.