Oauth - Authorization Code Flow


The authorization code grant type (flow) works with an intermediate credential called a authorization code.

It is a indirect and redirection-based flow that is optimized for confidential clients.

The client asks first for an authorization code that it is then used to obtain an access tokens (an optionally a refresh tokens) to get access to the protected resources. More on the flow ? See authorization code flow details

Pro and cons


The authorization code is obtained by using an authorization endpoint (authorization server component) as an intermediary between the client and resource owner (end-user).

Instead of requesting authorization directly from the resource owner,

sequenceDiagram participant CL as Client participant RO as End User (Resource owner) participant AS as Authorization Endpoint participant TE as Token Endpoint CL->>AS: (A) Makes a authorization request by redirecting the end-user browser RO->>AS: (B) The end-user authenticates and authorizes the client AS->>CL: (C) Send a authorization code grant CL->>TE: (D) Asks a access token with the authorization code grant TE->>CL: (E) Send a access token (and opt refresh)

The flow includes the following steps

(A) Authorization request

The client (app) initiates the flow by directing the resource owner's user-agent (end user using a browser) to the authorization endpoint.

See authorization endpoint authorization request

The client includes in this request:

(B) Authorization

The authorization endpoint (authorization server component):

  • authenticates the resource owner (via the user-agent)
  • establishes whether the resource owner grants or denies the client's access request.

(C) Redirection after grant

Assuming the resource owner grants access, the authorization endpoint (authorization server component) redirects the user-agent back to the client using the redirection URI.

The redirection URI includes:



Real example from Google Drive Local:



They are generally given back in the URL query.

It expose then the authorization code to:

  • browser history attacks,
  • redirect headers,
  • web log leaking
  • and so on.

That's why the authorization code is temporary.

Example in javascript where the URL is processed and the authorization code is deleted from the history.

// get the query string portion of the current url.
const queryString = window.location.search;
if (queryString.includes("code=") && queryString.includes("state=")) {

	// Process the query parameters, get the token ...

	// Update the ui with the new auth state

	// Remove the querystring parameters from the redirect
	window.history.replaceState({}, document.title, redirectPath);

(D) Client request access token

The client requests an access token from the authorization server's token endpoint by including the authorization code received in the previous step.

When making the request, the client authenticates with the token_endpoint (authorization server).

The client (app) includes the redirection URI used to obtain the authorization code for verification.

(E) Getting access token and, optionally, a refresh token

The token endpoint (authorization server component):

If valid, the token endpoint (authorization server component) responds back with an access token and, optionally, a refresh token.

Example of a call to


could result into

   "id_token":"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZ.... JWT",
   "scope":"openid profile email",

Documentation / Reference

Powered by ComboStrap