OAuth2.0 — For Absolute Beginners (Part 1)

Banujan Balendrakumar
SLIIT FOSS Community
5 min readJun 2, 2022
OAuth Logo | Source:- https://oroinc.com

Introduction 😊

OAuth stands for Open Authorization, Which is an open standard to provide Delegated Access to client applications without giving the password. OAuth is not an application or service that you can install and use. It is just an open standard, By following it you can implement OAuth in your application.

There are 2 versions, OAuth1.0 and OAuth2.0. Both are completely different, and cannot be used together. OAuth2.0 is the widely used version. Before diving into the topic, Let’s understand the problem that OAuth2.0 solves. In this story, I will explain the basic concept of OAuth2.0.

The Real Problem ⚠️

Before OAuth, Allowing apps to access particular data from another app was extremely difficult. Applications were using terrible methods to accomplish this.

Imagine the following scenario:

You are using a photo editor and that app wants to import photos from your google photos account directly. How can you permit the photo editor app to access your google photos?

The only way is to share your login credentials, So the photo editor logs into google photos for you and gets photos from your account. Of course, This is a stupid idea. The password should not be shared with anyone else. But before OAuth, 3rd party applications asked for the user’s password.

Before OAuth, Facebook was asking for the Gmail password to access friends’ email addresses.

So before OAuth, we had 3 major problems.

  1. Trust Issues 😒
    Even though 3rd party apps say “We don’t store your password”, We cannot trust them. We don’t know if they do anything else using our credentials.
  2. Credential Leakage 💧
    If those 3rd party apps store our Gmail or any other application credentials insecurely, A single security breach will expose all the connected app credentials.
  3. No Delegated Access ❌
    Once you gave your credentials, They can access everything in the application. We cannot restrict them to access only the particular data.
    Eg:- Facebook may say We only access emails, but what if they access the inbox messages?

To solve the issues mentioned above, The new Authorization Framework OAuth2.0 [RFC6749] was implemented.

OAuth 2.0 🛡

OAuth 2.0 obtains Limited Access to 3rd party applications without providing the password. Instead of validating the password, it validates special tokens called AccessToken and RefreshToken.

How does it work?

Well, I am pretty sure that everyone has seen this without knowing what it is 😂. Let me show you a quick demo.

Let’s say I want to allow Shutterfly to access my Google Photos, So it can access and show those in Shutterfly.

Connect Google Photos + Shutterfly
Connect Google Photos + Shutterfly

Now, I am gonna click on the “Connect” button to connect to my Google Account.

Google OAuth Login Screen for Shutterfly
Google OAuth Login Screen for Shutterfly

Now you can see, Instead of asking for my Email and Password, Shutterfly takes me to Google to log in. So, The Shutterfly never knows my Google credentials. I can securely log into Google.

Google OAuth Permission Request

Once you are logged into your google account, It will ask you “Hey, Shutterfly asking for these permissions. Can I allow it?”. Once you allowed it, Google sends the AccessToken and RefreshToken to Shutterfly.

Every time, when Shutterfly needs to do anything in my Google Photos account, It should submit the Access Token along with the request. Google Photos will validate this Access Token and check the permissions it has. If the Access Token is valid and the requested operation is granted, Google Photos will allow it. Otherwise, it will deny. The Access Token has an expiry date. If it is expired, Shutterfly needs to get a new Access Token using the Refresh Token.

As you can see We granted Limited Permissions (See, upload, and organize photos) to Shutterfly. That means, Shutterfly can’t do any other operations in my Google account except the scopes I allowed. This is called Delegated Access.

Before we move, Let’s see some terminologies.

  1. Authorization Server
    The party that authenticates the user and authorizes the scopes requested by the 3rd-party application. In the above example, it’s Google (https://accounts.google.com)
  2. Resource Server
    The party that has the resources. In the above example, The resource is your photos, and the resource server is Google Photos. (https://photos.google.com)
  3. Resource Owner
    The party that owns the resources. In the above scenario, You own your photos. So, The resource owner is You.
  4. Scopes
    Scopes are nothing, It is just the permissions requested by the 3rd-party application. Eg: — Read Emails, Access Contacts, and See Photos.
  5. Access Token
    A Token that is given by the Authorization Server to the 3rd-party app to access resources. When a 3rd-party app requests resources from the resource server, It Should submit this AccessToken. The resource server will verify the token and allow or deny based on the verification result.
    Eg:- 3MiOiJodHRwczovL2V4YW1wbGUuYXV0aDAuY29tLyIsImF1ZCI6Imh0dHBzOi8vYXBpLmV4YW1wbGUuY29tL2NhbGFuZGFyL3YxLyIsInN1YiI6InVzcl8xMjMiLCJpYXQiOjE0NTg3ODU3OTYsImV4cCI6MTQ1ODg3MjE5
  6. Refresh Token
    An Optional Token that is given by Authorization Server to the 3rd-party application to renew the expired access token.

The above terms are really important to understand the upcoming stories because we will be deep diving into OAuth2.0.

So, These are the basic concept of OAuth2.0. It provides a way to obtain limited access to 3rd-party applications to access particular resources only without exposing our credentials. It solves the 3 major issues that we saw earlier.

  1. Trustable 🤝
    Because We don’t submit credentials through the 3rd-party application. Instead, We directly log in from the application that the account belongs to.
  2. No Credential Leakage 💪
    Since the 3rd-party doesn’t know the credentials, We don’t need to worry about it. The Access Tokens are short-lived, So even if the 3rd-party application leak the Access Token, The attacker will have access for short time only.
  3. Delegated Access 🔒
    Since the Access Tokens are attached to the specific scopes, The 3rd-party application cannot perform any unauthorized operation.

Summery

I hope you understand the basic concept of OAuth2.0, In the upcoming stories, I will be deep-diving into OAuth2.0. We will be discussing some advanced topics such as Grant Types, Opaque and JWT Access Tokens, Securing Tokens & etc. So, Stay tuned and follow for more.

Thank you 🎉

--

--

Banujan Balendrakumar
SLIIT FOSS Community

Senior Software Engineer | AWS Certified Solution Architect | Auth0 Ambassador