The Authorization Code Flow

Why an intermediate code

Rather than handing tokens straight to the browser, this flow first returns a single-use authorisation code on the redirect. The client then swaps that code for tokens over a direct, server-to-server call known as the back-channel. The reason for the indirection is entirely about exposure: it keeps tokens off the address bar, out of browser history, and away from referrer headers that might leak them to third parties.

The exchange step also gives the client a chance to authenticate itself, so a stolen code on its own is not enough to obtain tokens. An attacker would also need the client's credentials, or, for public clients, the PKCE verifier. This layering is why the authorization code flow is the default recommended flow for the Merion API whenever a user is present, rather than any of the older alternatives.

Walking the steps

First, the client redirects the user to the authorisation server with its identifier, the requested scopes, a registered redirect URI, and a random state value. The user signs in and consents to the request. The server then redirects back to the registered URI carrying the authorisation code. Finally, the client exchanges that code at the token endpoint for an access token and, optionally, a refresh token.

GET /authorize?response_type=code
  &client_id=...&redirect_uri=...
  &scope=...&state=xyz

Each step exists for a clear security reason, which is exactly why skipping or shortcutting any of them weakens the whole flow. The redirect carries no tokens, the exchange happens privately, and the state value ties the two ends of the journey together so the response can be trusted.

Redirect URIs and state

The redirect URI must be registered in advance and matched exactly by the authorisation server. Exact matching is what prevents an attacker from diverting the authorisation code to a hostile site by tampering with the request; an unregistered or loosely matched URI is a classic source of token theft.

The state parameter is an unguessable value the client generates at the start and verifies when the response returns, protecting against cross-site request forgery on the callback. Treat both as strictly mandatory rather than nice-to-haves. Always compare the returned state to the value you originally sent before trusting anything in the response, and reject any mismatch outright instead of trying to recover from it. These two controls do a surprising amount of the flow's security work.

When to use it

Use the authorization code flow for server-rendered web applications that can safely keep a client secret on the backend. For mobile apps and single-page apps, which cannot keep a secret, use the same flow paired with PKCE and no secret at all. Deliberately avoid the legacy implicit flow, which returned tokens directly in the URL and is now formally discouraged because of that exposure.

The pattern is flexible enough to cover almost every user-facing case once you add PKCE for public clients. For those public clients, PKCE is essential rather than optional — see PKCE Explained for how it binds the exchange. To compare grants side by side and confirm your choice, read Choosing an Auth Flow.