OAuth 2.0 Overview: Protocol Basics, Core Concepts, Grant Types and Token Flow

OAuth 2.0 is an authorization framework that enables third‑party applications to obtain limited access to user resources without exposing user credentials. It replaces insecure methods such as HTTP Basic Authentication and supports scenarios like single sign‑on, OpenID, and federated identity.

Core Concepts

Resource Owner – the end user who authorizes access.

Resource Server – hosts protected resources and validates access tokens.

Client – the application requesting access on behalf of the user.

Authorization Server – authenticates the resource owner and issues tokens.

Key token types include access_token (short‑lived credential) and refresh_token (used to obtain new access tokens). The redirect_uri must be pre‑registered to prevent hijacking.

Grant Types

1. Authorization Code Grant

The most common flow for server‑side applications. The client redirects the user to the authorization endpoint, receives an authorization code, and exchanges it for an access token.

GET /authorize?response_type=code&client_id=YOUR_CLIENT_ID&redirect_uri=https://client.example.com/cb HTTP/1.1
Host: server.example.com

Token request example:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic BASE64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https://client.example.com/cb

2. Implicit Grant

Designed for pure front‑end applications where the token is returned directly in the URL fragment.

GET /authorize?response_type=token&client_id=YOUR_CLIENT_ID&redirect_uri=https://client.example.com/cb HTTP/1.1
Host: server.example.com

Successful redirect includes the token in the fragment:

Location: https://client.example.com/cb#access_token=TOKEN&token_type=Bearer&expires_in=3600&state=xyz

3. Resource Owner Password Credentials Grant

Used only when the client is highly trusted. The user supplies username and password directly to the client, which forwards them to the token endpoint.

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic BASE64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=SECRET

4. Client Credentials Grant

For machine‑to‑machine communication where no user is involved. The client authenticates itself and receives an access token.

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic BASE64(client_id:client_secret)
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

Token Refresh

When an access token expires, the client can request a new one using the refresh token:

GET https://b.com/oauth/token?grant_type=refresh_token&client_id=CLIENT_ID&client_secret=CLIENT_SECRET&refresh_token=REFRESH_TOKEN

All responses must include appropriate cache‑control headers (e.g., Cache-Control: no-store , Pragma: no-cache ) to prevent token leakage.

For detailed specifications, refer to RFC 6749, RFC 6750 and related drafts.