Mastering OAuth 2.0: Core Concepts, Grant Types, and Practical Implementation

OAuth 2.0 is a standardized authorization framework designed to replace insecure HTTP Basic Authentication and to enable secure, flexible access to protected resources without exposing user credentials. It is widely used for third‑party login, API access control, and single‑sign‑on (SSO) scenarios.

Typical Usage Scenarios

Third‑party login where an application needs to verify a user's identity.

API authentication to determine whether a request is permitted.

Core Concepts and Roles

Resource Owner : The entity (usually a user) that can grant access to protected resources.

Resource Server : Hosts the protected resources and validates access tokens.

Client : An application acting on behalf of the resource owner, requesting access tokens.

Authorization Server : Authenticates the resource owner and issues access tokens.

Key Token Types

Access Token : A short‑lived credential representing the client’s permission to access specific resources.

Refresh Token : An optional long‑lived credential used to obtain new access tokens without re‑authorizing the user.

Redirect URI : The client‑registered endpoint to which the authorization server redirects the user after granting or denying access.

Scope : A space‑separated list defining the permissions requested by the client (e.g., profile email).

OAuth 2.0 Authorization Flow

User accesses the client application and is prompted to authorize.

User consents to the requested permissions.

Client exchanges the received authorization code for an access token at the token endpoint.

Authorization server validates the request and issues the access token (and optionally a refresh token).

Client uses the access token to request protected resources from the resource server.

Resource server validates the token and returns the requested data.

Four Grant Types

1. Authorization Code Grant

Best suited for server‑side applications. The client redirects the user to the authorization server with client_id, redirect_uri, scope, and state. After user consent, the server redirects back with an authorization code. The client then exchanges the code for an access token.

Sample request:

GET /authorize?response_type=code&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https://client.example.com/cb HTTP/1.1

Sample token request:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

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

Successful response (JSON):

{
  "access_token": "2YotnFZFEjr1zCsicMWpAA",
  "token_type": "bearer",
  "expires_in": 3600,
  "refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
}

2. Implicit Grant

Designed for pure front‑end applications where a backend is unavailable. The client receives the access token directly in the URL fragment after user consent.

Sample request:

GET /authorize?response_type=token&client_id=s6BhdRkqt3&state=xyz&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcb HTTP/1.1

Successful redirect includes:

Location: http://example.com/cb#access_token=2YotnFZFEjr1zCsicMWpAA&state=xyz&token_type=bearer&expires_in=3600

3. Resource Owner Password Credentials Grant

Used only when the client is highly trusted (e.g., first‑party apps). The user provides username and password directly to the client, which forwards them to the token endpoint.

Sample request:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=password&username=johndoe&password=A3ddj3w

4. Client Credentials Grant

Applicable to machine‑to‑machine communication (e.g., CLI tools). The client authenticates itself using its own credentials and receives an access token.

Sample request:

POST /token HTTP/1.1
Host: server.example.com
Authorization: Basic czZCaGRSa3F0MzpnWDFmQmF0M2JW
Content-Type: application/x-www-form-urlencoded

grant_type=client_credentials

Token Refresh

When an access token nears expiration, the client can obtain a new one using the refresh token:

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

The refresh token must be stored securely on the server side; it should never be exposed to the user agent.

Security Recommendations

Always register exact redirect URIs and validate them during token exchange.

Use the state parameter to mitigate CSRF attacks.

Prefer the Authorization Code flow for confidential clients to keep client secrets off the browser.

Store refresh tokens securely on the backend and rotate them regularly.

Reference Links

RFC 5849 – The OAuth 1.0 Protocol

RFC 6749 – The OAuth 2.0 Authorization Framework

RFC 6750 – Bearer Token Usage

OAuth 2.0 Specification (https://oauth.net/2/)