Understanding OAuth2 and Its advantages: A Beginner’s Guide

This Beginner’s Guide provides a basic overview of OAuth2 and discusses how to build a simple OAuth2 authorization server.

As an application or a web developer, you may have heard of the term OAuth2.0, it has gained a lot of popularity and is now widely accepted for Authentication around the world. At a high level, it is a protocol in which two parties interact and share information in a secure environment. In this article, I will give you a high-level picture of OAuth2.0-based authentication and how to register an application to an OAuth service provider such as Google.

Authentication vs Authorization

These two terms are very popular in terms of validating the user logging into your website.

Authentication is the process of recognizing a user’s identity. It is the mechanism of associating an incoming request with a set of identifying credentials. 

Whereas Authorization is the process of determining what actions are allowed to perform once you have been authenticated.

Email / Password-based Authentication

There are many ways to authenticate a user, a very traditional way is to store the username and password.

The above figure shows a user is registered using an email id and password and the data is stored in the database. For security purposes, the password is hashed to protect the user’s data. The bigger challenge here for both the developer and end-user is to keep the data protected because hackers would always look for loopholes in the security hence we need a way to authenticate both the user on our behalf and also to keep the user data secure, that is when OAuth 2.0 comes into the picture

What problem does OAuth solve?

You may have come across, the below screen while trying to log in to a web or mobile application. It involves 2 things:

  • It allows a user to log into an application with another Social Media account. For example, you can log in to any application using your Facebook account or Google.
  • It allows one service to access the resources of another service. For example, signing into any gaming application using your Facebook account will give access/authentication to that app to post on your Facebook wall.

Advantages of OAuth

  • As a developer, you are responsible for identifying a user and securing the information.
  • As an end-user you are just using one account to log in to multiple services, hence there is no need to create and keep multiple accounts.
  • The application feels more secure for both the developer and end-user because OAuth providers are trusted names.
  • OAuth providers have a large team of engineers who are working to secure the data from hackers.

Client-Side vs Server-Side flow

Client-side flow is simple to implement and they are used purely for the browser-based applications using HTML/JavaScript. These applications may not have a backend server to store user information and they purely run on a browser. Let’s understand the client-side flow

Here user wants to access a simple browser-based application. The application sends the user to the 

OAuth flow and then to the authorization endpoints. OAuth server presents the consent screen to the user and when the user allows it, the server redirects the user back to the browser using redirect URI with the access token.

Client-side authentications are simple to implement but it is not a trusted source because the access token is not stored on the server but locally on the browser. Also, the access tokens are not stored for a longer time, which means that the client will need to re-authenticate the user when they would need to access the services again at a later date.

Now let’s see how the Server-side flow, authentication works

In the server-side flow client initiates the auth flow in a similar way, the server redirects the client using redirect URI with the auth code. The client then requests the access token by token endpoints including the authorization code received from the server. The client also includes the redirection URI which is used to obtain the Auth code. The auth server authenticates the client, validates the auth code, and ensures that the redirect URI matches the one it used to redirect the user before. If valid, the server then responds back with the access token and optional refresh token.

This implementation is complex in nature, but it is more secure because the access key is saved at the server and has long-term access to the key, necessary to access the user data. Any application that has a back end linked to a database is suitable to implement this flow.

In the server-side flow client initiates the auth flow in a similar way, the server redirects the client using redirect URI with the auth code. The client then requests the access token by token endpoints including the authorization code received from the server. The client also includes the redirection URI which it used to obtain the Auth code. The auth server authenticates the client, validates the auth code, and ensures that the redirect URI matches the one it used to redirect the user before. If valid, the server then responds back with the access token and optional refresh token.

This implementation is complex in nature, but it is more secure because the access key is saved at the server and has long-term access to the key, necessary to access the user data. Any application that has a back end linked to a database is suitable to implement this flow.

Register Application Using Google

I will explain here the registration process:

Google developer’s console for your applications to use Google’s OAuth.

  • Click on the O-Auth Consent screen

If you are a G-Suite owner must select internally, this process is used when you are developing an application to be used within your organization. Or you can select external to make your app available for anyone who is having a Gmail account.

For now, we will select external

  • In the next screen, you must provide your application information such as Application name, logo, support email, and scopes for API.

Scopes tell the user the kind of information the application is trying to access from the user’s Gmail account

by default, email, profile, and OpenID is selected, we can add scope depending on our requirements such as full access to read, write or delete email or calendar information. In this case, Google verifies the consent screen.

  • Now provide the domain name, and homepage link just like the below screen

If you are making an app for learning purposes, provide the localhost URL in the home page link or your application’s homepage.

  • Now select your project and click on credentials on the left panel
  • Select Create credentials at the top and select O-Auth Client ID.
  • Select the application type such as web application.
  • Put the URI for the respective JavaScript origins (used for client-side) or authorized redirect URI (used for server-side) now click create

Here I have put the dummy application URIs

  • Next, you will receive a Client Id and a Client Secret that will be used to initiate the Auth flow.

Here your registration is completed. Now one can use all the resources such as client id, client secret, and redirect URI to initiate the Auth flow that allows users to log in using their Gmail account. In addition to the simple login, the functionality can also be extended for a greater purpose. Because of this many organizations adopt it as an authorization layer internally.

The above blog is one of the many steps taken by our team at AFour Technologies towards our continuous efforts of educating businesses about various Cyber Security Testing threats. If this is something you or your business is also concerned about, our security experts would love to have a conversation with you.



Leave a Reply