OAuth API Documentation

What is an OAuth 2.0 Grant Type?

The OAuth 2.0 framework defines several grant types, or methods, that allow a client application to obtain an access token.
This token represents a user’s permission for the application to access their data and is used to securely authenticate requests to API endpoints.
Each grant type is designed for specific use cases,such as web applications, native mobile apps, devices without web browsers, or server-to-server integrations.

Supported OAuth 2.0 Grant Types:

  • Authorization code grant
  • Implicit grant
  • Client Credentials grant
  • Password grant
  • Refresh Token grant

Before we begin, here are the most common OAuth terms that we are going to use:

  • Resource Owner (User):
    The individual or entity that owns the protected resources. If this entity is a person, they are referred to as the end user.

  • Resource Server (API server / OAuth provider):
    The server that hosts and secures protected resources. It validates access tokens and responds to authorized API requests from clients.

  • Client (Application):
    The application that requests access to protected resources on behalf of the resource owner and with their authorization. A client can be a web app, mobile app, or server-side application. The term refers to its role, not its platform.

  • Authorization Server :
    The server responsible for authenticating the resource owner and issuing access tokens to the client once authorization is granted.

Grant Types

Authorization Code Grant

The Authorization Code Grant is one of the most widely used OAuth 2.0 flows.It’s ideal for web and native apps where a user authorizes an application to access their data. After authorization, the app receives an authorization code that can be exchanged for an access token.

You can read more about Authorization Code Grant Here: Authorization Code Grant

Implicit Grant

The Implicit Grant is designed for client-side applications that run entirely in the user’s browser (typically built with JavaScript).
Since this flow doesn’t involve any server-side code, the authorization server issues the access token directly to the client without an intermediate authorization code.

This makes the flow simpler but less secure, which is why it’s now being replaced by newer flows, such as Authorization Code with PKCE, in modern applications.

You can read more about Implicit Grant Here: Implicit Grant

Client Credentials Grant

The Client Credentials Grant is used for machine-to-machine (M2M) authentication.

In this flow, the client application authenticates itself directly with the authorization server using its own credentials. No user involvement is required.
Once verified, the authorization server issues a general access token that allows the client to access protected resources.

You can read more about Client Credentials Grant Here: Client Credentials Grant

Password Grant

The Resource Owner Password Credentials (ROPC) grant, commonly called the Password Grant, is used when the client application is highly trusted.

In this flow, the user provides their username and password directly to the application, which then sends these credentials to the authorization server in exchange for an access token.

You can read more about Password Grant Here: Password Grant

Refresh Token Grant

A Refresh Token allows an application to obtain a new Access Token (or ID Token) without requiring the user to log in again. This improves user experience and reduces unnecessary authentication requests. The refresh token remains valid until it expires or is revoked by the authorization server.

You can read more about Refresh Token Grant Here: Refresh Token Grant