OAuth vs. OAuth 2: differences + what you need to know

OAuth was built to allow one app to access another app on behalf of a user. The first version, OAuth 1.0, was released in 2007. However, as web apps evolved, OAuth 1.0 began to feel rather limited. 

OAuth 2.0 was introduced to address many of the pain points developers were facing with OAuth 1.0, including the complicated signatures and the poor support for non-browser-based apps.

In this article, we are going to discuss the differences between the two versions in detail, walk you through what’s changed, and explain what it means for you as a developer.

What's changed in OAuth 2.0, and what does it mean for you?

OAuth 2.0 is a complete overhaul of the original OAuth 1.0 spec: 

• It ditched OAuth 1.0's complex signatures and relies solely on HTTPS for security. 
• It uses short-lived tokens.
• It offers more authorization flows to accommodate different kinds of apps, from web mobile and desktop apps to APIs. 

Because of these changes, the way you do authorization using OAuth 2.0 is quite different from the way you would do it using OAuth 1.0. With OAuth 2.0:

• You don’t need to sign requests.
• You don’t have to make a single authentication flow work for all your apps.
• You now need to implement token state management to refresh expired tokens.

OAuth 1.0 to OAuth 2.0: Changes in detail

Here are the differences between OAuth 2.0 and OAuth 1.0 in detail.

OAuth 2.0 relies on HTTPS for security

OAuth 1.0 requires each request to be cryptographically signed with the app’s secret key. The downside of this is that if the key is compromised, an attacker can figure out how to generate their own signatures and access protected data. 

This doesn’t mean OAuth 1.0 is insecure. As long as the secret key is well secured, then the connection is secure. The issue is how complex generating signatures for each individual request can get. You’ll need to:

• Construct a unique signature base string by concatenating the HTTP method, the request base URL, and the normalized, percent-encoded request parameters. 
• Create the signing key by concatenating the consumer secret and token secret values. 
• Apply a cryptographic hashing algorithm (e.g. HMAC-SHA1 or RSA-SHA1) to the signature base string using the signing key.

OAuth 2.0 simplifies the process by delegating security to HTTPS. This means the data sent back and forth is encrypted via TLS, and you don’t have to worry about generating signatures for each request.

OAuth 2.0 separates the resource and authorization server

In OAuth 2.0, there’s a clear division of roles: the authorization server (the one that issues tokens) and the resource server (the one that holds the data) are separate.

These two roles can live on two different servers, they don't need to share data or infrastructure and can be scaled independently. 

Some providers even have one authorization server servicing multiple resource servers, meaning the authorization server can issue valid tokens across multiple servers.

Therefore, once you get a token, you can use it to access all APIs that accept that server’s tokens.

Access tokens have a short lifespan

In the earlier OAuth 1.0 version, access tokens had a longer lifespan, from a whole year to forever (like was the case with Twitter’s access token). This design meant that once an application obtained an access token, it could use it to access the user’s data on the resource server without needing to re-authenticate frequently. 

While convenient for both developers and users, this approach raised security concerns, especially if a token was compromised.

OAuth 2.0 changed this. 

Access tokens have expiry dates. They are short-lived, often lasting from several minutes to a few hours. They were introduced primarily to accommodate self-encoded tokens, also known as self-contained tokens, and include all the necessary information about the token’s validity and the permissions it grants.

They are typically encoded in a format like JWT (JSON Web Tokens). Their self-contained nature allows resource servers to validate these tokens independently without needing to perform a database lookup for each API call. It significantly enhances performance, especially for services processing a high volume of API requests.

But there’s a tradeoff. Once issued, they cannot be revoked before their expiration time. In OAuth 1.0, revoking a long-lived token was feasible through database lookups. However, with OAuth 2.0’s self-encoded tokens, the information about the token's validity is embedded within the token itself, making immediate revocation challenging. 

So, to limit the time an attacker can abuse a stolen token, these tokens must expire. To reduce the need to frequently ask users to re-authenticate, OAuth 2.0 uses refresh tokens. 

A refresh token has a longer lifespan and is used to obtain new access tokens without requiring the user to re-authenticate. Even if an access token is compromised, its short validity period limits the time an attacker can use it. 

This means that when building your OAuth 2.0 implementation, you’ll need a token management system that uses a refresh token to obtain a new token. 

Just make sure to keep the refresh token under wraps. The last thing you need is for an attacker to get a hold of it and continuously acquire new access tokens.

OAuth 2.0 has more than one authentication flow

OAuth 1.0 primarily defined a single standardized flow, rather than multiple flows, for different types of apps (web, mobile, desktop). This flow worked great in theory, but in practice, it was limiting for apps that didn’t live on the browser.

OAuth 2.0 supports six authorization flows (known as grant types), each specialized for a different type of app. 

For example, there’s an authorization code grant for server-side apps, a PKCE variation for client-side apps, and a device grant for authorizing devices that don’t have browser support.

These distinct flows offer a better developer experience. No more wrestling with a one-size-fits-all approach. Instead, you get to pick the grant type that works best for your app.

How does OAuth 2.0 work?

In OAuth 2.0, apps use access tokens to access protected data. How they get these tokens depends on the grant type they’re using.

The most used flow, the Authorization Code Flow, involves the following steps:

• The user initiates the process, and your app redirects them to the authorization server, where the user logs in and grants permission.

• After successful authentication and authorization, the authorization server redirects the user back to your app with an authorization code.

• Your app exchanges the authorization code for an access token (and optionally a refresh token) by making a server-side request to the authorization server. This request includes the application's client ID and client secret for authentication.

• Your app receives the access token (and refresh token) from the authorization server and can use the access token to make authorized API requests on behalf of the user.

The access token doesn’t last forever. If it expires and you still need access, you’ll have to request another one from the authorization server using the refresh token.

What can you do with OAuth 2.0 that you can't do with OAuth 1.0?

You can use OAuth 2.0 to:

• Authorize devices without browser support through the Device Authorization grant flow, e.g., smart TVs, media players, smart home assistants, and more. It’s what devices like Roku and Apple TV use to connect to streaming services, like Netflix or Spotify, instead of asking you to use your remote control to enter a username and password (which can be painstakingly slow).
• Authorize client-to-client connections via the client credentials grant flow. If you have a CLI client talking to a backend service, for example, the CLI client can acquire an access token from an OAuth server and use it to call the backend service.
• Authorize client-side public clients, like mobile and single-page apps, via the PKCE flow. PKCE is an extension of the OAuth 2.0 protocol that helps prevent code interception attacks and is the de facto flow for clients that cannot keep secrets.

Is there any benefit in sticking with OAuth 1.0?

If your application is already using OAuth 1.0 and the authorization flows are working smoothly without any issues, transitioning to OAuth 2.0 might not be beneficial. 

However, keep in mind that OAuth 2.0 has become quite popular, and unless you’re interacting with legacy APIs, you’ll probably need to use OAuth 2.0.

What's the difference between OAuth 2.0 and OIDC?

OAuth 2.0 is an authorization protocol, while ODIC (OpenID Connect) is an authentication protocol built on top of OAuth 2.0. It allows you to verify the identity of a user and obtain their identity information. In simpler terms, OIDC answers the question, "Who is this user?" OAuth, on the other hand, does not care about the user’s identity, it focuses only on what the user is allowed to access.

What is OAuth 2.1?

OAuth 2.1 is a proposed update to OAuth 2.0. Its main goal is to make OAuth simpler and more secure by bringing all the best practices and lessons learned since OAuth 2.0’s introduction under a single name.

To name just a few changes, it consolidates various extensions like Proof Key for Code Exchange (PKCE) into the main specification, removes insecure grant types like implicit grant and password grant flow, and limits refresh tokens for security purposes.

Adding OAuth to your app

Adding OAuth to your app isn’t necessarily difficult but can be extremely time-consuming. You will need to figure out how each provider implements OAuth (they each do it a bit differently), maintain security, and regularly update your integration to keep with changes in providers APIs. Not to mention that mistakes or omissions in the implementation can lead to data breaches.

It’s easier and way faster to use a done-for-you solution like WorkOS SSO API and connect to dozens of OAuth providers with just a few lines of code.

• Get started fast: With SDKs in every popular language, and Slack-based support, you can implement SSO and connect to OAuth providers in minutes rather than weeks.
  
  
• Support every protocol: With OAuth 2.0 integrations of popular providers like Google and Microsoft, compatibility with every major IdP, and full support for custom SAML/OIDC connections, WorkOS can support any customer out of the box.
  
  
• Avoid the back-and-forth: WorkOS’s Admin Portal takes the pain out of onboarding your customers’ IT teams and configuring your app to work with their identity provider.
  
  
• Pricing that makes sense: Unlike competitors who price by monthly active users, WorkOS charges a flat rate for each company you onboard — whether they bring 10 or 10,000 SSO users to your app.

‍

Explore Unified SSO by WorkOS.