OAuth 2.0 Overview

Introduction

This article only talks about OAuth protocol. In the next article, we will read about Open ID Connect aka OIDC in short form.

Oauth is the industry-standard protocol for authorization. OAuth1 is deprecated which is the first version of the Oauth protocol. Currently, OAuth 2.0 is the standard protocol that is in existence.

Before we dive into these Oauth and Open ID Connect protocols let's understand, how the authentication and authorization took place back in the initial web days. For this let's consider a simple login scenario, where a user enters a user name and password in the form. This can also be considered as forms-based authentication.

The basic request flow is as follows below,

the user enters the credentials
your code checks for user existence in backend DB
the code validates the user and password hash,
On successful validation, it sets a cookie on the browser that has session-id to track the user session and max-age.

The downside of this approach is,

need to write additional code for authentication and authorization
maintenance of the identity infrastructure with the latest industry standards
The chances of getting the ids compromised are high.

Let's try to understand the below terms, which are important before diving into OAuth and Open ID protocols.

Authentication - validate who you are accessing the resources
Authorization - what access you have on resources

What is Oauth Pattern

Have you ever seen a screen like, hey the app wants to have permission to read your basic information

profile information
contacts
No ability to post on your behalf

This is basically known as OAuth patterns, where the app is acting on your behalf getting access to basic profile information such as your Facebook profile, Google profile, linked-in profile, etc.

bBack in the days when Oauth was coming into the industry, they were literally asking for your password, which basically gets to your profile information, and accesses the contacts and then destroys the password. You never give the password in third-party sites your Google or Facebook accounts. Below is a Yelp example when it was a basic start-up asking for the password.

OAuthflow is a better way

We need to understand, what is delegated authorization first. In the delegated authorization, the app has access to only the service it wants based on users consent. Let's say you have an application called myjukebox.com, and its tries to access your Facebook contacts. Following is the flow that is involved to have your app get access to your Facebook contacts.

On your client application there is a button called connect with Facebook. The application also sends basic information in addition it sends redirect uri. This ‘redirect uri’ is the destination, where the request needs to be sent on successful authentication and consent.
Users request is sent to facebook authorization server, where prompted for user name and password. This is happening at trusted site, where an user can feel more comfortable.
On successful authentication, it prompts with a pop-up message, ‘Are you sure you want to grant access your application access to your contacts’? this is called ‘Authorization Grant’.
If user clicked ‘yes’ it is called successful grant. On successful grant, user being redirected to your application redirect location which is mentioned in very first call. the authorization provider which is here facebook, will send the authorization code in the request. the process of obtaining the authorization code on successful authorization grant is called ‘Authorization code grant’.

Your application sends authorization code to authorization server again (‘accounts.fb.com’), saying 'Hey here is the authorization I got on user’s consent, but I need access token to access the contacts.'
The authorization server, checks the authenticity of the code, and then gets the access token
This access token will have access only to do certain tasks, in this case read contacts.
Note that using this access token, the application has very limited access, that is it cannot post on user’s wall, creating new contacts, deleting contacts etc.

Why can’t we get the access token on the successful access grant?

Why the additional overhead of getting an authorization code from authorization server and then your client application exchanging the authorization code with authorization server to get access token?

Before answering this question let's understand the channels of communication first.

Front channel

The communication that is happening from the browser. This can be seen from browser URLs and the network trace information using fiddler and developer tools. in the block diagram the solid arrow denotes front channel communication. passed as query parameters on the request.

Back channel

The communication from where your backend code or server communication which is via a secure channel which can’t be tracked by fiddler or any developer tools.

The access token is treated as sensitive information. This token is created based on the scopes and permission to resources, that client application is requesting. To reduce the chances of getting the sensitive information compromised, the access token is exchanged with back channel.

Oauth2.0 Terminology

The OAuth2.0 protocol involves following terms now we could better understand.

Resource Owner

The person who owns the resource. In other words, it can be termed as person interacting with client application.

Client

It is the application you are interacting with. In our case it is myjukebox.com

Authorization Server

The server that takes the responsibility of authenticating and authorizing the request. Here it is accounts.fb.com

Resource Server

The server holding the resources. In our case it is contacts.fb.com

Authorization Grant

The consent accepted by user after it is given by authorization server.

Redirect URI

The request that is being redirected to the client application, after successful grant.

Access Token

The token received by your client application on exchange with Authorization code provided by Authorization Server on successful authentication. The token exchange happens via back channel for security. It is a http post with the authorization code along with the secret key (which is only known by exchange server) to get the access token.

Initial setup is to set up the application with client ID and client Secret with service/developer portal. This way the authorization server knows requests coming from your application

Client ID

The ID of the client application set up at authorization server portal during the app registration process. This information is sent with the request to authorization server via front channel.

Client Secret

The secret that is generated by authorization server for the registered client during the app registration process. this information is sent with authorization code to server via back channel in exchange of access token.

Note

The get token request action is done via Token End Point to get access token. communication to resource owner is also done through back channel using the access token.

state

It can be considered as a simple text value that sent over and gets back at end.

scopes

The authorization server understands the scopes such as.

· profile.read()
· profile.write()
· contacts.read()
· contacts.readwrite()

During the registration process, the scopes will be defined for the application to get proper access to resources like reading profile, reading contacts etc.

consent

Based on the scopes defined for the application, the auth server generates the consent screen. For instance, if the application is registered to scope ‘contacts. read()’ then a message displays saying the jukebox application is requesting access to read your facebook contacts. are you sure you want to allow? “

Request Flow

Now Lets try to understand the request flow

Step 1

Starting the flow. When the user clicks on ‘connect facebook’ an url will be constructed.

The request has following details defined

client_id
redirect_uri
scope
response_type
state

Step 2

On successful consent, user gets the following code, as the response type is requested as code in initial request.

Step 3

Now your client application exchanges this authorization code with authorization server for access token. this occurs at back channel and this is http post request to authorization server.

Step 4

Authorization Server returns token in the following format.

Step 5

This access token is used by your client application to access the resources. This also happens via back channel. This is also sometimes referred as bearer token.

Types of Oauth flows

Authorization code

The flow we have seen so far, where both front channel and back channel is used to get authorization code and access token.

Implicit

The communication happens via front channel only i.e browser. lets consider you have single page application that is built on react or angular and there is no backend server that hosts the code, in this case you will directly get access token from the authorization server.

Resource owner password credentials

This flow requests users’ credentials via interactive form. Because these credentials are sent via back channel, these can be stored for future use to get access token. This should be only used, where ‘Authorization Code’ flow wouldn’t work.

Client Credentials

This also happens via back channel only. This happens when one service talks to other services using client ID and client secret to authenticate to get access token.

Conclusion

Thus in this article, we have gone through what is OAuth and how the Oauth flow occurs and different types of OAuth flows.

References

https://OAuth.net/2/
https://www.youtube.com/watch?v=996OiexHze0&t=2415s&ab_channel=OktaDev
https://auth0.com/docs/flows/resource-owner-password-flow
https://auth0.com/docs/flows/client-credentials-flow