Oauth2 Introduction

OAuth (Open Authorization) is a simple way to publish and interact with protected data. It is an open standard for token-based authentication and authorization on the Internet. It allows an end user's account information to be used by third-party services, such as Facebook, without exposing the user's password.

Oauth used for

Consider the use case of Quora.com, while doing signup as shown below we can see an option like you can signup using google or facebook. When doing so you are authorizing Google or Facebook to allow quora to access you profile information with Quora. This authorizing is done using OAuth. Here you have in no way shared your credentials with Quora.
In the above example of Quora, we have 4 actors

  1. Resource Owner - This is the user who wants to sign up using Quora.
  2. Client Application - This will be Quora
  3. Resource Server - This will be Gmail or Facebook.
  4. Authorization Server - The resource server hosts the protected user accounts, and the authorization server verifies the identity of the user then issues access tokens to the application.


Now lets implement our own client application and resource server. The resource owner will then using OAuth authorize the resource server to share data with the client application. The client application must first register with the authorization server associated with the resource server. This is usually a one-time task. Once registered, the registration remains valid, unless the client application registration is revoked. At registration the client application is assigned a client ID and a client secret (password) by the authorization server. The client ID and secret is unique to the client application on that authorization server.


Similar to the above flow we will be developing our own client application and Resource Server. Using OAuth the Resource server will then share the data with the client application. Also we will be assuming that the client is already registered with the Resource Server and has been assigned a unique client id and secret key.

Access Token

In OAuth 2.0, an access token is a credential used by an application to access an API on behalf of a user. It represents the authorization granted to the application by the user and is issued by the authorization server. Access tokens are typically short-lived and have an expiration time after which they become invalid.

  1. Authorization Grant: Before an access token is issued, the application must obtain authorization from the user. This is usually done through an authorization grant, such as the user logging in with their credentials or giving consent to the application.
  2. Issuance: Once authorized, the authorization server issues an access token to the application.
  3. Usage: The application includes the access token in API requests to authenticate the user and access protected resources on the user's behalf. The token acts as a bearer credential, meaning whoever possesses the token can access the associated resources.
  4. Scope: Access tokens may include information about the permissions granted (scope) to the application. This determines what actions the application can perform on behalf of the user.
  5. Expiration: To mitigate security risks, access tokens have a limited lifespan. After expiration, the application must obtain a new access token using a refresh token (if applicable) or by repeating the authorization process.
  6. Security: It's crucial to secure access tokens because they grant access to user data. Applications should store tokens securely and use secure communication channels (HTTPS) to transmit tokens.

Refresh Token

In OAuth 2.0, a refresh token is a special token used to obtain a new access token when the current access token becomes invalid or expires. Refresh tokens are typically long-lived compared to access tokens and are used to maintain persistent access to resources without requiring the user to re-authenticate.

  1. Purpose: Refresh tokens are used to obtain new access tokens without prompting the user to re-enter their credentials or re-authorize the application. This improves user experience by reducing the frequency of login prompts.
  2. Issuance: When a user initially authorizes an application, along with the access token, the authorization server may issue a refresh token. Not all authorization grants or scenarios result in the issuance of a refresh token; it depends on the OAuth 2.0 flow being used.
  3. Usage: When an access token expires or becomes invalid (e.g., due to session timeout or token expiration), the application can use the refresh token to request a new access token from the authorization server. This process is typically done programmatically by the application behind the scenes.
  4. Security: Refresh tokens should be kept secure because they grant long-term access to resources. They are usually stored securely on the client side (e.g., in a secure cookie or local storage) and transmitted over secure channels (HTTPS) to prevent interception.
  5. Lifetime: Refresh tokens have a longer lifespan compared to access tokens. The exact duration varies depending on the authorization server's policies and the OAuth 2.0 implementation being used. They are typically revoked only when explicitly requested by the user (e.g., through logout) or by the application owner.
  6. Revocation: Authorization servers may support revoking refresh tokens if they are compromised or no longer needed. This allows for better security management.