Overview
OAuth (Open Authorization) is an open-standard authorization framework that enables applications to obtain limited access to user resources on another service without exposing the user’s credentials. Instead of sharing passwords, OAuth issues access tokens to third-party applications, allowing them to act on behalf of the user for specific scopes and durations.
Why OAuth matters
OAuth improves security and user experience by:
– Avoiding password sharing between services.
– Limiting the scope and lifetime of access via tokens.
– Enabling delegated access (e.g., allowing an app to read a user’s calendar without accessing the user’s login credentials).
Core Concepts
Resource Owner: The user who owns the data.
Client: The application requesting access to the resource.
Resource Server: The API server that hosts the user’s protected resources.
Authorization Server: The server that authenticates the resource owner and issues access tokens.
Access Token: A credential used by the client to access protected resources.
Refresh Token: (Optional) A credential used to obtain new access tokens when the current one expires.
Scope: The set of permissions the client requests.
OAuth 2.0 Flows (Grant Types)
OAuth 2.0 defines several flows for different scenarios. Common ones include:
Authorization Code Grant: Recommended for server-side and native apps. Involves redirecting the user to the authorization server to authenticate and consent, then exchanging an authorization code for an access token.
Implicit Grant: Historically used for browser-based apps (now discouraged due to security concerns).
Client Credentials Grant: Server-to-server authentication where no user is involved; the client app authenticates itself to get an access token.
Resource Owner Password Credentials: User provides credentials directly to client (recommended only for highly trusted clients; discouraged otherwise).
Simple Authorization Code Flow (high-level)
1. Client redirects the user to the Authorization Server’s authorization endpoint.
2. User authenticates and grants consent.
3. Authorization Server redirects back with an authorization code.
4. Client exchanges the authorization code for an access token (and optionally a refresh token).
Example HTTP exchange (Authorization Code -> Token)
Exchange an authorization code for an access token (POST):
POST /oauth/token
Host: authorization-server.com
Content-Type: application/x-www-form-urlencoded
grant_type=authorization_code&code=AUTH_CODE&redirect_uri=https%3A%2F%2Fclient.example.com%2Fcallback&client_id=CLIENT_ID&client_secret=CLIENT_SECRET
Sample token response:
{
"access_token": "2YotnFZFEjr1zCsicMWpAA",
"token_type": "Bearer",
"expires_in": 3600,
"refresh_token": "tGzv3JOkF0XG5Qx2TlKWIA"
}
Security best practices
– Use HTTPS for all authorization and token requests.
– Prefer Authorization Code Grant with PKCE for public/native clients.
– Keep client secrets secure (do not embed in public SPA/mobile apps).
– Use short-lived access tokens + refresh tokens when needed.
– Validate scopes and audience on the resource server.
– Implement token revocation and rotation when possible.
OAuth vs OpenID Connect
OAuth is strictly an authorization framework. OpenID Connect (OIDC) is an identity layer built on top of OAuth 2.0 that provides ID tokens and standardized user profile endpoints for authentication and identity.
Wrap-up
OAuth is a foundational standard for modern delegated authorization. Understanding its components, flows, and best practices is essential for building secure integrations between services.