A Beginner’s Guide to Oauth 2.0

This article is the simplified format of the Oauth 2.0 specification standardized by IETF. Initially, I found the specification a bit confusing and difficult to understand. So I thought, why not write a small article to describe it in simpler words. The main aim of writing this article is to provide an overview of Oath 2.0 and get familiarize with the terminologies.

Problem statement

Let's start with an example to understand this better.

Let's say we want to build one appointment booking app. This app requires access to the user’s google calendar data to write and post invitations to google calendar on the user’s behalf. One simpler way to achieve this is if users are ready to share their credentials with this app. But there are many potential problems(shared below) with sharing the username and password with the third-party apps.

  1. Third-party apps will be required to store user’s credentials in their system for future usage.
  2. Third-party apps gain broader access. Sharing google credentials will not only give access to their calendar data but all the google apps like Gmail, Drive, Wallet, etc. Which users might not have intended to do.
  3. Users can not revoke access from any particular third-party app. The only way to revoke access would be to change the password.
  4. If the third-party application data is compromised, the user’s credentials might also get compromised.

So the main problem statement that we have is

How to share limited data with third-party applications without sharing credentials.

Oauth 2.0 specification is designed to solve these problems where third-party apps can use Oauth 2.0 to obtain permission to access protected resources of users and users can grant limited access to resources to third-party apps for a certain period.

What is Oauth 2.0

As per definition from RFC6749 by IETF,

The OAuth 2.0 authorization framework enables a third-party
application to obtain limited access to an HTTP service, either on
behalf of a resource owner by orchestrating an approval interaction
between the resource owner and the HTTP service, or by allowing the
third-party application to obtain access on its own behalf.

In simpler words,

Oauth 2.0 allows sharing protected resources or data of end-users with third-party applications without sharing user’s credentials and keeping their username and password safe.

Oauth 2.0 Terminologies

Before we go over how Oauth 2.0 works, let's go over few terminologies which will be helpful to understand the overall flow. From now we will be using the below terminologies throughout this article.

  1. Resource Owner: Resource owner is referred as end-users who own resources. Resource owners grants access to their protected resources to third-party apps via OAuth 2.0
  2. Resource Server: A resource server is referred to as an entity or server that holds and protects resources. It provides access to the resources via APIs after authentication and authorization. In the above example, the google calendar server or APIs can be referred to as a resource server.
  3. Client: Third-party app or entity that requests access to protected resources on behalf of the Resource Owner. In the above example, a booking app can be referred to as a client.
  4. Authorization Server: An authorization server is referred to as an entity or server that is responsible for Authentication and Authorization. It provides an access token to clients for accessing resources on Resource owners’ behalf.
  1. Access Token: An access token is a bearer token used to access the resources via resource server APIs. An access token has a limited life. It's a type of bearer token which means anyone having access token can access resources. The resource server do not validate identify again if the access token is valid and provide access to resources.
  2. Refresh Token: Refresh token is used to obtain a new access token from the Authorization server without asking the resource owner to provide access. The life of the refresh token is always higher than that of the access token. This is mainly used for convenience and a better user experience where the user does not require to log in again and again once the access token is expired.
  3. Authorization code: Authorization code is a temporary code, issued by the Authorization server to clients which later clients can exchange with an access token and refresh token by providing client secret. This is getting used in the Authorization code grant on Oauth 2.0 flow. This allows end-users to see what resources are requested by clients and accordingly can approve or decline the request.

Endpoints

  1. Authorization Endpoint: This endpoint is getting used by clients to get authorization of protected resources. Authorization server provides authorization code to clients after Resource owners grant access to requested Resource via scope. here scope defines the amount of access that is granted to an access token or resource owner. In some OAuth flows, This endpoint can also provide an access token to clients directly.
  2. Token Endpoint: This endpoint is getting used by clients to get an access token and refresh token from the Authorization server by presenting them Authorization code.

Overall Flow

  1. Client requests for an access token to Authorization server along with clientId and scope and redirect URI.
  2. The authorization server will send the login page and consent form to the Resource owner.
  3. The resource owner will verify the scope and see what all details are requested by the client. After verifying it will grant access.
  4. The authorization server will generate an Access token for the client and send it client via redirection URL.
  5. The client will make an API call to the Resource server to access resources with the access token.
  6. The resource will request an Authorization server to validate the access token.
  7. The authorization server will send confirmation if the token valid.
  8. If the token valid, the Resource server will send a response with the requested Resources.

Oauth 2.0 Grant types

To obtain an access token from the Authorization server, clients need to present authorization from the resource owner. The authorization is expressed in the form of an authorization grant, which the client uses to request the access token. In simpler words grant types as different methods to obtain an access token and refresh token from the Authorization Server. OAuth has defined below four grant types.

  1. Authorization code grant
  2. Implicit grant
  3. Client credentials grant
  4. Resource owner password credentials grant

Let's go through each grant type and understand when and where should we use these.

Authorization code grant

  1. Authorization request from the client to Authorization Server with a client identifier requested scope, redirect URI to which the authorization server will send the user-agent back once access is granted (or denied).
  2. The authorization server authenticates the resource owner
  3. Resource owner grants or denies the client’s access request.
  4. The authorization server redirects back to the client using the redirection URI provided earlier along with the Authorization code
  5. Client requests an access token to Authorization server with Authorization code (received in step 4), client identifier, client secret, and redirect URI
  6. The authorization server authenticates the client, validates the authorization code, and redirection URI. If all good, the authorization server sends back an access token and, optionally, a refresh token.

The rest of the steps are the same as we discussed in the overall flow.

  1. Most secure flow in Oauth. This provides three-leg security. Identify will be checked for all three actors. ie. Resource owner, client, and Resource server.
  2. This flow is also more secure since it sends the access token directly to the client without exposing it to others through the user agent.
  3. The most commonly used grant type
  4. Can obtain both access token and Refresh token
  5. More convenient for resource owner since it provides Refresh token. The client can renew the access token directly with the authorization server
    without authenticating the Resource owner
  1. Involves more round trips than other flows
  2. Not suitable for apps that can not securely store client secret or autonomous apps

Implicit Grant

  1. Authorization request from the client to Authorization Server with a client identifier requested scope, redirect URI to which the authorization server will send the user-agent back once access is granted (or denied).
  2. The authorization server authenticates the resource owner
  3. Resource owner grants or denies the client’s access request.
  4. The authorization server redirects back to the client using the redirection URI provided earlier along with the Access token

The rest of the steps are the same as we discussed in the overall flow.

  1. Suitable for public clients or user-agent-based clients ie. SPA
  2. Returns Access token directly without intermediate code exchange
  3. Simple to implement
  4. A refresh token is not provided in this flow
  5. Recommended short validity of access tokens
  1. Less secure since an access token is directly returned in the URL
  2. Less convenient for the Resource owner since it does not return a refresh token

Client credentials grant

  1. The client requests an access token to the Authorization server via token endpoint with client credentials. ie. Client Identifier and Client Secret
  2. The authorization server authenticates clients and if client credentials are valid then issue access token.

The rest of the steps are the same as we discussed in the overall flow.

  1. This flow uses client identifiers and client secrets to authorize and access protected resources.
  2. Suitable for the server to server authentication where a specific user’s permission not required
  3. Also can be used when the client itself is the resource owner

Resource owner password credentials grant

  1. Resource owners provide the client with its username and password
  2. The client requests an access token from the authorization server with the Resouce owner's password credentials.
  3. The authorization server authenticates the client and validates the resource owner’s credentials and if valid then issues an access token and optional refresh token.
  1. Resource owner’s password credentials grant uses the username and password of the resource owner to authorize and access protected resources
  2. Suitable in few cases where the resource owner has a high level of trust with the client. ie. Operating system
  1. User credentials are exposed to the client.
  2. The client can access all the protected resources of the resource owner

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store