What Is OAuth Exactly And How Does It Work?

A deep dive into Oauth – how it works and it’s usage with Google services

August 3, 2023 | Feature Highlight | Google Cloud |

What Is OAuth Exactly And How Does It Work?

Since the beginning of internet, it’s been tough for people to keep a track of their passwords. They either forget them or use the same password everywhere. This is where oauth enters, which provides users a safe way to access services without entering their passwords. How? Let’s understand what is oauth and how it works through this article.

Before diving deep into OAuth let’s understand 2 words clearly i.e. Authentication and Authorization. There’s a lot of confusion around this and it will be a good idea to make it clear before going through the article.

Authentication: This is when a user proves their identity by either password, tokens, etc.

For example: When you enter the airport you are asked for an official Govt. Document to prove who you are claiming to be.

Authorization: This is when a user is given certain roles and permissions which is associated with limited access to resources, actions, etc.

For example: There are certain rooms and places in the airport that normal citizens are not allowed to enter. It specifically requires an ID card, etc to enter.

Overview of OAuth 2.0

OAuth stands for ‘Open Authorization’, it’s an authentication and authorization framework that allows applications, RESTful APIs, Microservices etc to gain limited to full access to certain resources which otherwise is only possible when users themself request it.

It’s like someone is carrying out an operation on your behalf. Let’s look at some use cases to understand this better.

Use Cases of OAuth 2.0

We as users go through the process of OAuth 2.0 on a regular basis. Let me point some of them out:

So you listen to your favorite music on Spotify, there are high chances that you must’ve used Login With Google or Login With Facebook as the option rather than typing your id and password.

Let’s deep dive here to understand what happens, for the sake of example, I will be considering Google as the OAuth 2.0 provider

  1. Spotify sends an authorization request on your behalf to Google.
  2. You see a popup from Google that mentions all details Spotify is requesting and whether you want to allow Spotify to access that or not.
  3. Once you allow it, google sends an authorization grant to Spotify which is used later to authenticate itself to google.
  4. Spotify sends this Authorization Grant to Google, post verifying the authenticity of the Authorization Grant Google sends the Access Token.
  5. Now, Spotify uses this access token to request information like basic user details i.e. name, gender, age, etc from google
  6. Google checks the access token’s validity and shares the requested details
  7. And that’s how your Spotify account got created and you are now logged in!

Here’s a flow diagram of the steps explained above:


Similarly, there are a dozen other applications like Quora, Uber, Instagram, etc that use OAuth 2.0 to onboard their users.

Oauth Roles

Let’s look into each component and their roles in Oauth 2.0 –

  1. Application – This is the systems that needs access to the user’s data. It must be authorized by the user and should have a valid access token.
  2. Resource Owner – This owns the user’s data and can grant access to it.
  3. Resource Server – As seen in the above diagram, resource servers accepts an access token, validates it, and returns desired resources.
  4. Authorization Server – This receives request from the application for access tokens and grants it after successful authentication from the resource owner.

OAuth 2.0 vs OAuth1.0

OAuth 2.0 is the successor of OAuth 1.0, so its obvious that it has filled some gaps that were there in OAuth, additionally focused on ease of usage. Let’s discuss some of these points:

Comparison of User Experience And Security Attributes


  1. 1. Support for All types of applications

    • OAuth 1.0 only supported browser applications, therefore desktop and mobile applications had to redirect user to browser to complete the authentication and get back the tokens.
    • OAuth 2.0 solves this problem because it has a different authorization flow that is initiated by these applications.
    • However, when using OAuth 2.0 with non-browser base applications it is advised to follow the best practices from https://tools.ietf.org/html/rfc8252
  2. 2.Easy Implementation

    • OAuth 1.0 validated the exchange of data between client, server and resource server with the help of a shared secret. This secret was also used to sign the authorization request made by client and the server signed with the client’s key to validate the legitimacy of the exchange. Since this dealt with a lot of exchanges of keys it faced a lot of criticism for implementation by developers.
    • OAuth 2.0 has given the major security responsibilities to the way HTTPS operates, it can only be implemented where SSL and TLS are made available. It uses the privacy properties included with TLS communication.


Comparison in a nutshell

OAuth 1.0 OAuth 2.0
It is transport-independent i.e. it does not carry out authorization with SSL / TLS but rather follows some different protocol. It is transport-dependent i.e. SSL / TLS plays a major role from the security perspective.
Uses digital signatures for authenticity and integrity of messages ensuring tight security. Uses bearer tokens, JWT for security, which is not great as they do not have internal security mechanisms.
Difficult to implement. Easy to implement.
Not flexible as it only handles web-flows or browser based applications. Much more flexible as it considers all non-brwoser based applications.
Tightly coupled as only one server is responsible for authorization and resource sharing. Decoupled as resource requests and user authorization are handled by different servers.
Access Tokens are long-lived in nature and could be stored for a year or more. Access Tokens are short-lived, and refreshed in regular interval of time.

Can I use OAuth 1.0?

It is not advisable to use OAuth 1.0 because a lot of resource providers like Google have completely moved to OAuth 2.0. There are still some providers like Twitter that completely support OAuth 1.0

Steps to use Google APIs with OAuth 2.0

Google APIs like maps, translation, calendar, people, etc use OAuth 2.0 protocol for authenticating and authorizing requests. To start using these APIs you need to create OAuth 2.0 credentials from Google Cloud Console.

Let’s take a look at the 5 steps that needs to be followed to access Google APIs with OAuth 2.0:

  1. Create OAuth 2.0 credentials 
    1. Open Google API Console to create the relevant credentials such as Client ID and Client secret, etc depending on the application you are using. Google and your application store these secrets.


  2. Create an access token 
    1. You need an access token to access the private data, this token is created with the help of credentials from step 1.
    2. A request is sent from your application to Google on behalf of you. Google then shows the user a list of permission the application is requesting for. These permissions are defined under a parameter called scope.
    3. Once the user grants any one of the permission, Google returns an Access Token and a list of scopes where this token is valid. Google returns a server error if none of the permission is granted.
    4. If your application needs multiple permissions, it is a best practice to request for permissions eventually, this is known as Incremental Authorization.


  3. Scope Examination of access permitted by user 
    1. The scopes listed in the access token response is compared with the scopes required to access resources via specific google APIs.
    2. For instance, the user receives access token to read resources from people API. But if the user tries to update a contact with the same token this request fails; as the token’s scope doesn’t matches the requesting scope.


  4. Send the access token to the API 
    1. After receiving the access token, it is sent to a Google API in HTTP Authorization request header. It is advised to share this token with headers only and not via query params; as these requests are usually stored as logs.


  5. Refresh the access token, when needed 
    1. As mentioned in the comparison above, access tokens of OAuth 2.0 are short-lived and your requests will fail once these tokens are expired.
    2. Along with the access token, Google provides us a refresh token. This refresh token is used to create new access token which should replace the expired one.

OAuth 2.0 in Microservice based architecture

In distributed systems, service-to-service (microservice) communications happen very frequently. These communications need to be authenticated and authorized. Some oAuth providers such as Google provides this facility. This needs a service account which is different than that of an individual account. We will take a look at the steps to create.

Creating a service account


    1. Open the Service accounts page.
    2. Select an existing project, or create a new.
    3. Click + Create service account.
    4. Fill in the details under Service account details for the service account and proceed.
    5. We can also grant the IAM roles to this service account from Grant this service account access to project section. Note: This step is optional.
    6. Click Continue and Done to complete the steps..


To use the above service account we need to have a key, following are the steps to create one:


    1. Click + Create key, then click Create
    2. Choose the email address you want to associate with the service account you created.
    3. Click the Keys tab.
    4. Select Create new key from the Add key drop-down list.
    5. Click Create.


With this we will have the public / private key. Store the private key carefully, as if we lose it there will be no way to recover it other than creating a new one by following the above steps to create one.

Use appropriate and official libraries from Google to make authorized API Calls.

Wrapping Up

In this article we learned about OAuth, its security attributes, its working and why its a good choice to use to secure our RESTful APIs, Microservices, applications, etc.

Although it may be complex to implement, it takes care of the complete authentication and authorization module for your projects. You can easily decouple the authentication module from your system and not to mention the industry standards that you would be following with OAuth.

To understand more about Oauth and how it can increase your chances towards building a successful company, schedule a free consultation with our team of qualified cloud engineers.


Harsimran Singh Bedi

Ashok Hirpara

Cloud Native Software Engineer Team Lead
Software Engineer with 7+ years of experience offering technical expertise in programming languages, building cloud native software development and databases. Strong believer of documentation, code quality with 100% test coverage, security and scalability.

Related Posts

What Our
Clients Are

Working with D3V was hands down one of the best experiences we’ve had with a vendor. After partnering, we realized right away how they differ from other development teams. They are genuinely interested in our business to understand what unique tech needs we have and how they can help us improve.

Lee ZimbelmanWe had an idea and D3V nailed it. Other vendors that we had worked with did not understand what we were trying to do – which was not the case with D3V. They worked with us through weekly meetings to create what is now the fastest and most accurate steel estimating software in the world. Could not have asked for anything better – what a Team!

We used D3V to help us launch our app. They built the front end using React and then pushed to native versions of iOS and Android. Our backend was using AWS and Google Firebase for messaging. They were knowledgeable, experienced, and efficient. We will continue to use them in the future and have recommended their services to others looking for outside guidance.

Constrained with time and budget, we were in search of an experienced technology partner who could navigate through the migration work quickly and effectively. With D3V, we found the right experts who exceeded our expectations and got the job done in no time.

Protecting our customers data & providing seamless service to our customers was our top priority, which came at a cost. We are very satisfied with the cost savings & operational efficiency that D3V has achieved by optimizing our current setup. We’re excited about future opportunities for improvements through deriving insights from our 400 million biomechanics data points.

Our experience with D3V was fantastic. Their team was a pleasure to work with, very knowledgeable, and explained everything to us very clearly and concisely. We are very happy with the outcome of this project!

Jared Formanr

Jared Forman

CEO & Co-Founder, OSMix Music

Lee Zimbelmanr

Lee Zimbelman

IT Director, BLI Rentals

Terry Thornbergr

Terry Thornberg

CEO, Fabsystems Inc.

David Brottonr

David Brotton

CEO & Founder, Squirrelit

Dr. A. Ason Okoruwar

Dr. A. Ason Okoruwa

President, Bedrock Real Property Services

Ryan Moodier

Ryan Moodie

Founder, DARI Motion

Schedule a call

Book a free technical consultation
with a certified expert.

Schedule Call

Get an estimate

Fill out our form to hear back with a project’s cost estimate. No meeting required.

Get Estimate

Get in touch

Send a message to D3V team.

Let’s Talk