Authorization Code Flow

The core security mechanism involves a two-stage handshake. First, the client receives a short-lived authorization code via the user's browser. Second, the server-side client exchanges this code for the access token and refresh token via a secure, back-channel request using its client secret. This prevents the access token from ever being exposed to the browser or end-user.

• Stage 1 (Front-Channel): User authenticates, grants consent, and an authorization code is returned via redirect.
• Stage 2 (Back-Channel): Client exchanges code + secret for tokens directly with the authorization server.

This flow is explicitly designed for confidential clients—applications capable of securely storing a client secret. The secret is used to authenticate the client to the authorization server during the code-for-token exchange. This requirement distinguishes it from flows for public clients (like SPAs or mobile apps) and is fundamental to its security model.

• Examples: Traditional web applications with a server-side backend component (e.g., Python/Django, Java/Spring, Node.js).
• Security Implication: The client secret never leaves the protected server, preventing theft from a user's device.

By keeping the access token off the front-channel (user's browser), the flow inherently protects against several common web threats. The authorization code itself has limited value without the client secret.

• Browser History/Logs: The access token is not written to browser history via URL parameters.
• Referrer Headers: The token is not leaked to other sites via the HTTP Referer header.
• Intermediate Proxies: The token is not visible to any proxies between the user and the client app, as it is transmitted server-to-server.

While designed for confidential clients, the flow can be secured for public clients (like mobile and single-page apps) using the Proof Key for Code Exchange (PKCE) extension. PKCE adds a cryptographically bound key to the flow, preventing authorization code interception attacks.

• Code Verifier: A high-entropy random string created by the client.
• Code Challenge: A transformed version (e.g., SHA256 hash) of the verifier, sent with the initial authorization request.
• Binding: The original verifier must be presented when exchanging the code for the token, proving the same client initiated the request.

The Authorization Code flow is the primary OAuth 2.0 grant where refresh tokens are commonly issued. This allows applications to obtain new access tokens after the short-lived one expires without requiring the user to log in again, providing a seamless user experience while maintaining security.

• Long-Lived Sessions: Refresh tokens enable persistent sessions (e.g., "Keep me signed in").
• Reduced Credential Exposure: The user's password is not re-entered frequently.
• Revocability: Refresh tokens can be individually revoked by the authorization server if compromised.

This flow forms the backbone of OpenID Connect, the identity layer on top of OAuth 2.0. When used with the openid scope, the authorization server returns both an access token and an ID token (a signed JWT containing user identity claims). This enables secure authentication and standardized user profile access in addition to authorization.

• Single Sign-On (SSO): Enables federated identity across multiple applications.
• Standardized Claims: Provides a consistent way to retrieve user information like email and name.
• Hybrid Flows: Can be combined with other response types (e.g., code id_token) for optimized performance.

OAuth 2.0 is the overarching authorization framework that defines the Authorization Code Flow. It is an industry-standard protocol that allows third-party applications to obtain limited access to a user's resources on an HTTP service without ever handling the user's credentials.

• Provides the architectural blueprint for all grant types (flows).
• Delegates user authentication to the service hosting the user account.
• Separates the role of the client from the resource owner.

An Access Token is the credential obtained by the client application at the end of the Authorization Code Flow. It is a string (often a JWT) that represents the authorization granted to the client.

• Bearer Token: The most common type, where possession of the token grants access.
• Contains scopes defining the permissions granted.
• Has a limited lifetime, requiring refresh or re-authentication.
• Presented to the Resource Server to access protected APIs.

The Authorization Server is the central OAuth 2.0 component that orchestrates the Authorization Code Flow. It authenticates the user, obtains consent, and issues tokens.

Key responsibilities:

• Hosts the /authorize and /token endpoints.
• Validates the client's identity (Client Authentication).
• Issues Access Tokens and Refresh Tokens.
• May provide a Token Introspection endpoint for resource servers to validate tokens.

PKCE (pronounced 'pixie') is a critical security extension to the Authorization Code Flow, designed to protect public clients (like mobile and single-page apps) from authorization code interception attacks.

Mechanism:

1. Client creates a cryptographically random code verifier.
2. Derives a code challenge and sends it with the initial authorization request.
3. Later, when exchanging the code for a token, the client must present the original code verifier.
4. The authorization server verifies the challenge matches the verifier.

• RFC 7636 defines the standard.

A Scope is a mechanism in OAuth 2.0 that limits an application's access to a user's account. During the Authorization Code Flow, the client requests specific scopes, and the user consents to them.

• Represented as a space-separated list of strings (e.g., read:contacts write:calendar).
• Defines the permissions embedded in the resulting Access Token.
• Enables the principle of least privilege by granting only the access needed.
• Resource servers must validate that the token's scopes permit the requested action.

OpenID Connect is an identity layer built on top of the OAuth 2.0 Authorization Code Flow. It adds authentication semantics, allowing the client to verify the user's identity.

Extends the flow by:

• Returning an ID Token (a signed JWT) alongside the Access Token.
• The ID Token contains claims about the authenticated user (e.g., sub, email).
• Standardizes userinfo endpoints to fetch profile data.
• Transforms OAuth from pure authorization into a full federated identity protocol.