Oauth - Authorization Code Flow
Table of Contents
About
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
Articles Related
Pro and cons
- Because the resource owner (end-user) only authenticates with the authorization server, the resource owner's credentials are never shared with the client (app)
Flow
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,
- the client directs the resource owner to an authorization server (via its user-agent through redirection),
- authorization endpoint (authorization server component) in turn directs the resource owner (end-user) back to the client (app) with the authorization code.
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:
- its client identifier,
- local state (query parameter and value that comes back with the response),
- and a redirection URI to which the authorization server will send the user-agent back once access is granted (or denied).
(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:
- and any local state provided during Authorization request.
With SPAs (Javascript browser client call), they are given back in the URL query which can expose them to:
- browser history attacks,
- redirect headers,
- and so on.
https://example.com/redirection/path?code=xxxxx&state=xxxxx
The process will looks like that in javascript.
// 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 ...
process();
// Update the ui with the new auth state
updateUI();
// 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):
- validates the authorization code,
- and ensures that the redirection URI received matches the URI used to redirect the client in step (C).
If valid, the token endpoint (authorization server component) responds back with an access token and, optionally, a refresh token.
Example of a call to
https://tenant.example.com/oauth/token
could result into
{
"access_token":"yhEvm8U6uG0gPmoUDuLn3bENGIMceiFz",
"id_token":"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCIsImtpZ.... JWT",
"scope":"openid profile email",
"expires_in":86400,
"token_type":"Bearer"
}