OAuth 2.0 Protocol Overview: Concepts, Grant Types, and Implementation Details

OAuth 2.0 is an open authorization framework that enables third‑party applications to obtain limited access to protected resources without exposing user credentials, making it suitable for scenarios such as third‑party login, API authorization, and single sign‑on.

Core roles defined by the RFC: Resource Owner (the user), Resource Server (hosts protected resources), Client (the application requesting access), and Authorization Server (issues tokens after authenticating the user).

Key concepts: an access_token represents the granted permission and has a limited lifetime; a refresh_token can be used to obtain a new access token when the original expires; the redirect_uri must be pre‑registered to prevent hijacking; scope defines the permission set.

OAuth 2.0 flow (high‑level): the user is redirected to the Authorization Server, grants consent, the server redirects back to the client with an authorization code (or token), and the client exchanges the code for an access_token at the token endpoint.

Grant Types

1. Authorization Code Grant – most widely used for server‑side applications. The client sends a request like GET /authorize?response_type=code&client_id=YOUR_ID&redirect_uri=YOUR_URI&state=xyz , the user authorizes, and the server redirects with code=... . The client then POSTs to the token endpoint with grant_type=authorization_code , code , redirect_uri , client_id , and client_secret to receive a JSON response containing access_token (and optionally refresh_token ).

2. Implicit Grant – designed for pure front‑end applications. The initial request uses response_type=token . After user consent, the Authorization Server redirects to the client’s redirect_uri with the token in the URL fragment (e.g., #access_token=...&token_type=Bearer&expires_in=3600 ), which the client extracts via JavaScript.

3. Resource Owner Password Credentials Grant – used only when the client is highly trusted. The client sends a POST request to the token endpoint with grant_type=password , username , password , and optional scope . A successful response returns an access_token (and optionally a refresh_token ).

4. Client Credentials Grant – for machine‑to‑machine communication. The client POSTs grant_type=client_credentials (and optional scope ) to the token endpoint, authenticating with its client_id and client_secret . The server returns an access_token that represents the client’s own privileges.

All grant types share common token‑endpoint request parameters such as grant_type , client_id , and client_secret . Successful token responses are JSON objects containing at least access_token and token_type , optionally expires_in , refresh_token , and scope . Error responses include error , error_description , and error_uri fields.

Refresh Token Usage – when an access token is about to expire, the client can request a new one by calling the token endpoint with grant_type=refresh_token , refresh_token , client_id , and client_secret . The server validates the refresh token and issues a fresh access token.

Security considerations include strict validation of the redirect_uri , protecting client_secret on server‑side only, using HTTPS for all exchanges, and limiting token lifetimes to reduce impact of leakage.

References: RFC 6749 (OAuth 2.0 Authorization Framework), RFC 6750 (Bearer Token Usage), RFC 5849 (OAuth 1.0), and the OAuth 2.0 specification website.