Understanding OAuth 2.0: Authorization Flows Explained

OAuth 2.0 is the industry-standard protocol for delegated authorization. It allows users to grant third-party applications access to their resources without sharing passwords. If you’ve ever clicked “Sign in with Google” or authorized a GitHub app, you’ve used OAuth 2.0. This guide explains the core concepts and the most important grant flows.

OAuth 2.0 Core Concepts

OAuth 2.0 defines four roles: the Resource Owner (the user), the Client (the app requesting access), the Authorization Server (issues tokens), and the Resource Server (hosts the protected data). The goal is for the client to obtain an access token from the authorization server, then use that token to access the resource server.

Authorization Code Flow

This is the most secure and widely recommended flow for server-side apps. The client redirects the user to the authorization server with a client ID and requested scopes. The user authenticates and consents. The server redirects back with a short-lived authorization code. The client exchanges the code (plus a client secret) for an access token on the back channel. The code is single-use and the token exchange happens server-to-server, never exposing tokens in the browser.

Authorization Code Flow with PKCE

PKCE (Proof Key for Code Exchange) extends the authorization code flow for public clients like SPAs and mobile apps that cannot safely store a client secret. The client generates a random code_verifier and its SHA-256 hash (the code_challenge). The challenge is sent with the initial auth request; the verifier is sent during token exchange. This prevents authorization code interception attacks.

Client Credentials Flow

Used for machine-to-machine (M2M) communication where there is no user involved. The client authenticates directly with the authorization server using its client ID and secret, and receives an access token. Common in microservices, cron jobs, and backend integrations.

Implicit Flow (Deprecated)

The implicit flow returned tokens directly in the URL fragment, which exposed them to browser history and referrer headers. It is now deprecated in OAuth 2.1. Use PKCE instead for all public clients.

Scopes and Consent

Scopes define what access the client is requesting. Examples include read:user, repo, or openid email. The authorization server presents these scopes to the user for approval. Always request the minimum scopes necessary — this is the principle of least privilege applied to OAuth.

Token Types and Lifetimes

OAuth 2.0 access tokens are typically short-lived bearer tokens (minutes to hours). Refresh tokens allow clients to obtain new access tokens silently. OpenID Connect adds an ID token (a JWT) containing user identity claims on top of OAuth 2.0’s authorization layer.

Need to decode an OAuth token? Use the JWT Decoder and Base64 Decoder tools on devutilitypro.com to inspect access and ID tokens from your OAuth flows.