Authorization Code Grant
An OAuth 2.0 grant type where the client receives an authorization code via a browser redirect and exchanges it server-side for tokens, keeping tokens off the front channel.
Description
The Authorization Code Grant is the most secure and recommended OAuth 2.0 flow for applications with a server-side component. It involves two steps: first, the user authenticates with the authorization server and consents to the requested scopes, receiving an authorization code via browser redirect to the client's registered callback URL. Second, the client exchanges this short-lived authorization code for access and refresh tokens by making a back-channel (server-to-server) request to the token endpoint, authenticating with its client credentials.
The security advantage of this flow lies in the separation of channels: the authorization code travels through the front channel (browser redirect, potentially visible in browser history and logs) but is useless without the client secret. The actual tokens are delivered through the back channel (direct HTTPS request from client server to authorization server), never exposed to the user's browser. The authorization code is also single-use and short-lived (typically 30-60 seconds), further limiting the window for interception attacks.
The flow begins with the client redirecting the user to the authorization endpoint with parameters: response_type=code, client_id, redirect_uri, scope, and state (CSRF protection). After authentication and consent, the authorization server redirects back to the redirect_uri with the code and state parameters. The client verifies the state matches, then exchanges the code at the token endpoint with the code, client_id, client_secret, and redirect_uri. For public clients (SPAs, mobile apps), PKCE replaces the client secret. OAuth 2.1 makes PKCE mandatory for all authorization code grants.
Prompt Snippet
Implement the OAuth 2.0 Authorization Code Grant flow. Initiate by redirecting to the authorization endpoint with response_type=code, client_id, redirect_uri (must exactly match registered URI), scope, state (cryptographic random, stored in session for verification), and code_challenge/code_challenge_method for PKCE. On callback, verify the state parameter matches the session value, then exchange the authorization code at the token endpoint via server-side POST with grant_type=authorization_code, code, redirect_uri, client_id, client_secret (or code_verifier for PKCE). Store the returned access_token and refresh_token server-side. Never expose tokens to the browser.
Tags
Related Terms
OAuth 2.0
An authorization framework that enables third-party applications to obtain limited access to a web service on behalf of a resource owner.
OAuth 2.0 PKCE Flow
An extension to the OAuth 2.0 authorization code flow that prevents authorization code interception attacks using a dynamically generated cryptographic code verifier.
Client Credentials Grant
An OAuth 2.0 grant type for server-to-server authentication where the client authenticates directly with its own credentials, without a user context.
Scope-Based Permissions
A permission model where access tokens carry scope strings that define the specific actions and resources the token is authorized to access.
Token Revocation
The mechanism for invalidating issued access or refresh tokens before their natural expiration, typically triggered by logout, password change, or security events.