An Introduction to OAuth

Have a look at this picture below.

I’m sure you have come across this while signing up for an account in many websites. And if you have tried signing in like this, you would know how convenient this is. But do you know how this works? How do websites use this for user authorization? How does this feature improve security?

Curious? Let’s dive right into the blog!

What is OAuth?

OAuth, or open authorization, is a widely adopted authorization standard that allows you to consent to an application interacting with another third-party service on your behalf without having to reveal your password.

The main advantage of this authorization standard is that it provides applications with secure designated access so that users can engage with the secure portions of a website without the need to create a new account with new credentials.

How does OAuth work?

OAuth uses access tokens to grant temporary access to third parties, without exposing user credentials. The tokens are typically used short term, but some can grant recurring access as well. Let me give you a great example to understand the working.

Think of the separate valet key you would give to a valet when parking your car. The valet key is not the same as the main key because it only gives the valet limited access to your car. A valet key will not open the trunk or a locked glove box, so the valet cannot access any personal, valuable items. Some valet keys have further limitations, such as allowing the car to only be driven a certain number of miles.

An OAuth token functions the same way. A website or service is provided a different “valet” key and never has the "main" key to access any of the private data or credentials contained in the “main” key.

OAuth Flow

Now, let’s actually understand the technicalities of how OAuth works. Assume a user has already signed in to a website or service, and now the user wants to initiate a transaction that needs access to a third-party site or service. The authorization process follows the steps below:

  1. The application requests authorization to access a protected service provider (like Google, Facebook, Twitter).
  2. The user authorizes the request.
  3. The application provides proof of user authorization to the service provider in exchange for an access token.
  4. The user is redirected to the service provider to provide permission.
  5. Once approved by the user, the application obtains the access token.
  6. The application requests access to the protected resources from the service provider.

How is it beneficial?

The greatest benefit of OAuth for a website, such as a news, community, or e-commerce site, is that authenticated website access can be extended to an unlimited number of additional users without those users creating new accounts requiring an email address and a new password. Open authorization reduces friction for both parties. Websites can scale, and users do not have to create yet another online account.

Further, there is more security. When a user joins a website by signing in with Facebook, for example, if that website becomes the target of a cyberattack, users who logged in with OAuth will not have their credentials exposed or stolen.

A common misconception…

OAuth is about authorization and not authentication - and yes, there is a difference. Authentication is proving your identity so that you can gain access to an application or system. Authorization is asking for and receiving permission to access specific features or areas of that application or system. OAuth does not pass credentials between users and service providers and instead only authorizes secure access in the form of temporary tokens.

OAuth 1.0 vs. OAuth 2.0

OAuth 1.0 and 2.0 are very different from each other. OAuth 1.0, which is now deprecated, was designed specifically keeping websites in mind. It was considered too complicated and did not scale much. On the other hand, OAuth 2.0 provides authorized access to application programming interfaces (APIs) and encrypts the tokens in transit, so there is no need for encryption at the endpoints. It was designed to be more interoperable between sites and devices. Another great feature introduced was token expiration, which did not exist in version 1.0.

So, this brings us to the end of this blog. I hope you enjoyed it and found it useful. Feel free to share your thoughts on this topic in the comments section below.

Connect with me on LinkedIn