Understanding OAuth 2.0 Flow: Complete Diagram and Implementation Guide

Source: Dev.to

What Is OAuth 2.0?

OAuth 2.0 is the industry-standard authorization framework that enables third-party applications to obtain limited access to a user’s resources without exposing their credentials. Instead of sharing passwords, OAuth 2.0 uses access tokens—short-lived, scoped strings that grant specific permissions to specific resources. If you’ve ever clicked “Sign in with Google” or authorized a GitHub app to access your repositories, you’ve used OAuth 2.0. The protocol was formalized in RFC 6749 and has become the backbone of modern API authorization across the web. OAuth 2.0 is not an authentication protocol by itself—it is an authorization framework. Authentication (proving who you are) is handled by extensions like OpenID Connect (OIDC), which layers identity on top of OAuth 2.0. Understanding this distinction is critical to building secure systems. Before diving into the flows, let’s define the four roles that appear in every OAuth 2.0 interaction: The entity that owns the protected data—usually the end user. When you authorize Spotify to read your Facebook profile, you are the Resource Owner. The application requesting access to the Resource Owner’s data. Clients are classified as confidential (can securely store a secret, e.g., a backend server) or public (cannot store secrets, e.g., a single-page app or mobile app). The server that authenticates the Resource Owner and issues access tokens. Examples include Google’s OAuth server, Auth0, Okta, and Keycloak. It exposes two key endpoints: the authorization endpoint (user-facing) and the token endpoint (machine-to-machine). The API that hosts the protected resources. It validates the access token on each request and returns data if the token is valid and has the required scopes. For instance, the GitHub API is the Resource Server when a third-party app reads your repositories. The Authorization Code flow is the most secure and widely recommended OAuth 2.0 grant type for server-side applications. It involves a front-channel redirect to the authorization server and a back-channel token exchange, ensuring the access token never touches the browser. User clicks “Login” — The Client redirects the user’s browser to the Authorization Server’s /authorize endpoint with response_type=code, client_id, redirect_uri, scope, and a random state parameter. User authenticates — The Authorization Server presents a login screen. The user enters credentials and consents to the requested scopes. Authorization code issued — The Authorization Server redirects back to the Client’s redirect_uri with a short-lived authorization code and the original state value. Client validates state — The Client checks that the returned state matches the one it sent. This prevents CSRF attacks. Token exchange — The Client’s backend sends a POST request to the /token endpoint with the authorization code, client_id, client_secret, and redirect_uri. Tokens returned — The Authorization Server responds with an access_token, a refresh_token (optional), token_type, and expires_in. API call — The Client uses the access token in the Authorization: Bearer header to call the Resource Server. +----------+ +---------------+ | | (1) Authorization Request | | | User / | -----------------------------> | Authorization | | Browser | | Server | | | | | +----------+ +---------------+ | | | (3) Redirect with code + state | v | +----------+ | | | (5) Exchange code for token | | Client | ----------------------------------------> | (Server) | | | | | Resource | | | | Server | | | | | | | (2) authorization_code | | | | | | Server computes: | | SHA256(code_verifier) | | == stored code_challenge? | | | | (4) access_token | | | | | | | | | | | Authorization | | | | Server | | | | Authorization | | | (5) Logs in + consents | Server | +----------+ +---------------+ | +----------+ | | | (6) Poll POST /token | | Device | grant_type= | | | device_code | | | ----------------------------------------> | | | | | Client Credentials Flow │ (M2M, microservices, cron jobs) │ └── Yes │ ├── Can the client store a secret securely? │ ├── Yes ──> Authorization Code Flow + PKCE │ │ (Web backends, confidential clients) │ │ │ └── No ──> Authorization Code Flow + PKCE │ (SPAs, mobile apps, public clients) │ └── Is the device input-constrained? └── Yes ──> Device Authorization Flow (Smart TVs, CLIs, IoT)

Not

ice that Authorization Code + PKCE appears for both confidential and public clients. This is intentional. PKCE adds security with minimal complexity, and the OAuth 2.0 Security BCP recommends it universally. There is no modern scenario where the Implicit flow is recommended. +----------------------------+------------------+------------------+ | Scenario | Recommended Flow | Refresh Tokens? | +----------------------------+------------------+------------------+ | Server-rendered web app | Auth Code + PKCE | Yes | | Single-page application | Auth Code + PKCE | Yes (rotate) | | Native mobile app | Auth Code + PKCE | Yes (rotate) | | Backend microservice | Client Creds | No (re-request) | | CLI / developer tool | Device Auth | Yes | | Smart TV / game console | Device Auth | Yes | | Legacy browser app | Auth Code + PKCE | Migrate away | +----------------------------+------------------+------------------+

Use this checklist before deploying any OAuth 2.0 implementation to production: Use Authorization Code + PKCE for all user-facing flows Generate a cryptographically random state parameter and validate it on callback Register exact redirect_uri values—no wildcards, no open redirects Request the minimum required scopes (principle of least privilege) Validate all redirect URIs server-side before issuing codes Keep access token lifetimes short (5–15 minutes) Implement refresh token rotation Store tokens server-side whenever possible (BFF pattern for SPAs) Never store tokens in localStorage or sessionStorage

Set HttpOnly, Secure, and SameSite flags on all cookies Implement token revocation on logout Validate JWT signatures using the provider’s JWKS endpoint Verify the aud (audience), iss (issuer), and exp (expiration) claims on every token Use TLS (HTTPS) for all OAuth 2.0 endpoints—no exceptions Implement rate limiting on token endpoints to prevent brute-force attacks Log authentication events for security monitoring and incident response Rotate client secrets periodically Never log tokens—use token identifiers or hashes for debugging Handle all OAuth error responses gracefully (invalid_grant, invalid_client, etc.) Implement automatic retry with exponential backoff for transient token endpoint failures Force re-authentication when refresh token rotation detects reuse Return generic error messages to end users—never expose OAuth error details in the UI OAuth 2.0 remains the foundation of modern API authorization. While the protocol offers multiple flows for different scenarios, the industry is converging on a clear recommendation: use Authorization Code + PKCE for all interactive flows and Client Credentials for machine-to-machine communication. The Implicit flow is officially deprecated, and the Device Authorization flow fills the gap for input-constrained devices. The most important takeaway is that OAuth 2.0 security depends as much on implementation quality as on flow selection. Proper state validation, secure token storage, short token lifetimes, refresh token rotation, and JWT signature verification are all non-negotiable in production systems. Use the checklist above as your pre-launch security review, and always stay current with the OAuth 2.0 Security Best Current Practice RFC. JWT Decoder to inspect token claims during development. For a deeper dive into JWT structure and validation, read our guide on JWT Token Explained.

Free Developer Tools

If you found this article helpful, check out DevToolkit — 40+ free browser-based developer tools with no signup required. Popular tools: JSON Formatter · Regex Tester · JWT Decoder · Base64 Encoder 🛒 Get the DevToolkit Starter Kit on Gumroad — source code, deployment guide, and customization templates.