← Return to Pantheon

Codeus, The Three-Step Sovereign

Master of the Authorization Code Flow

Essential Flow

"I am Codeus! Master of the Three Sacred Steps! No token shall be granted without proper ceremony, no credential shall pass through the browser's treacherous lands! I ensure that access tokens NEVER touch the mortal's browser, for only the back-channel may bear these precious artifacts!"

Mortal Translation

The Authorization Code flow is the most secure OAuth 2.0 flow for web applications that have a backend server. It uses a two-step process: first obtaining an authorization code through the browser (front-channel), then exchanging that code for tokens via a secure server-to-server request (back-channel). This ensures that access tokens never pass through the user's browser where they could be intercepted.

The Three Sacred Steps

User

I wish to authenticate!

Application

Divine Commentary: The mortal seeks access to protected resources.

Application

Redirect to Authorization Server with client_id, redirect_uri, scope, and state

User

Divine Commentary: BEHOLD! The sacred pilgrimage begins! The application redirects the mortal to my temple with proper credentials.

User

Presents credentials and grants consent

Auth Server

Divine Commentary: The mortal must PROVE their identity! Only the worthy may proceed.

Auth Server

Returns authorization code via redirect_uri

Application

Divine Commentary: I grant the SACRED CODE! But beware - it is useless without the secret handshake that follows!

Application

Exchanges code + client_secret + redirect_uri for tokens

Auth Server

Divine Commentary: The back-channel ritual! Here, in the shadows away from mortal browsers, the true exchange occurs.

Auth Server

Returns access_token, refresh_token (optional), and token metadata

Application

Divine Commentary: Victory! The sacred tokens are granted! Go forth and access the divine resources!

⚡ Interactive Flow Simulator

Experience the Authorization Code flow step-by-step with visual animations

Flow Visualization

🌐
Browser
🔐
Auth Server
🖥️
Backend
🟦 Front-channel
1

User Initiates Login

User clicks "Login with OAuth" button in the browser

The flow starts in the browser when the user explicitly initiates authentication. Your app will redirect them to the authorization server.

2

Redirect to Authorization Server

3

User Authenticates & Grants Consent

4

Authorization Code Returned

5

Exchange Code for Tokens

6

Tokens Received

7

Access Protected Resources

The Divine Purpose

Codeus speaks: "I was created for web applications that can keep secrets! Unlike my foolish cousin, the Implicit Flow (may she rest in deprecation), I ensure that access tokens NEVER pass through the browser's perilous front channel!"

In mortal terms: This flow is designed for traditional web applications (with a backend) where you can securely store a client secret. The authorization code itself is useless without the client secret, providing an extra layer of security.

The Sacred Ritual

Step 1: The Redirect

Your application redirects the user to the authorization server with parameters includingclient_id,redirect_uri,scope, andstate (for CSRF protection).

Step 2: User Consent

The user authenticates with the authorization server and grants permission to your application. The auth server then redirects back to your application with an authorization code.

Step 3: Token Exchange

Your backend server exchanges the authorization code along with yourclient_secretfor access and refresh tokens. This happens securely on the back-channel.

Ancient Wisdom (Best Practices)

  • Always use HTTPS - The gods decree: never send sacred tokens over insecure channels!
  • Validate the state parameter - This protects against CSRF attacks
  • Keep client_secret secure - Never expose it in client-side code or version control
  • Use short-lived access tokens - If compromised, the damage window is limited
  • Implement refresh token rotation - Enhanced security for long-lived sessions

Forbidden Arts (Common Mistakes)

  • Using this flow for SPAs or mobile apps without PKCE - These cannot securely store client secrets
  • Ignoring the state parameter - You invite CSRF demons into your application
  • Storing tokens in localStorage - Vulnerable to XSS attacks; use httpOnly cookies instead
  • Not validating redirect_uri - Opens the door to authorization code interception

The Mortal's Guide to Implementation

Authorization Code Flow Implementationjavascript
// Step 1: Redirect user to authorization server
function initiateOAuthFlow() {
  const authUrl = 'https://auth-server.com/oauth/authorize';
  const params = new URLSearchParams({
    response_type: 'code',
    client_id: 'your-client-id',
    redirect_uri: 'https://yourapp.com/callback',
    scope: 'read write',
    state: generateRandomState() // CSRF protection
  });

  window.location.href = `${authUrl}?${params}`;
}

// Step 2: Handle the callback with authorization code
async function handleCallback(authCode, state) {
  // Verify state parameter matches (CSRF protection)
  if (state !== getStoredState()) {
    throw new Error('State mismatch - possible CSRF attack!');
  }

  // Exchange code for tokens (server-side only!)
  const tokenUrl = 'https://auth-server.com/oauth/token';
  const response = await fetch(tokenUrl, {
    method: 'POST',
    headers: {
      'Content-Type': 'application/x-www-form-urlencoded',
    },
    body: new URLSearchParams({
      grant_type: 'authorization_code',
      code: authCode,
      redirect_uri: 'https://yourapp.com/callback',
      client_id: 'your-client-id',
      client_secret: 'your-client-secret' // Keep this secret!
    })
  });

  const tokens = await response.json();
  // tokens = { access_token, refresh_token, expires_in, token_type }

  return tokens;
}

// Step 3: Use the access token
async function fetchProtectedResource(accessToken) {
  const response = await fetch('https://api.example.com/data', {
    headers: {
      'Authorization': `Bearer ${accessToken}`
    }
  });

  return response.json();
}

When to Consult Codeus

Traditional Web Applications

You have a backend server that can securely store secrets

Server-Side Rendered Apps

Next.js, Ruby on Rails, Django, Laravel, etc.

Maximum Security Required

When handling sensitive data or operations

For SPAs and Mobile Apps

Consult the PKCE Guardian instead - he protects applications that cannot keep secrets

Consult Also With

🛡️ PKCE Guardian - For single-page applications and mobile apps (Authorization Code + PKCE)

👑 Machinus - For machine-to-machine communication without user involvement

Divine Decree: RFC 6749 Section 4.1