Authorization code flow usage

Use Case Scenario

This use case demonstrates the different steps required to execute an authorization code flow with user interactions.

Overview of Steps

  1. A client starts an authorization code flow (authorize call).
  2. The user is authenticated and accepts the consent request.
  3. The client receives the authorization code.
  4. The client sends the authorization code to the AS and exchanges it for an ID, access, and refresh token (token call).

Step 1 – Start the Authorization Code Flow

To start the authorization code flow, open a browser window and enter the following URL:

Browser URL to start an authorization code flow
    response_type=code    &redirect_uri=
  • To successfully start an authorization code flow, the following conditions must be met:
  • A redirect_uri must be present in the request.
  • The redirect_uri must be on the list of redirect_uris registered during client registration.
  • A client_id must be present.
  • The scope "openid" must be present.
  • One additional scope must be present, if the authorization server has required scopes configured.
  • The redirect_url must be URL encoded.

If one of the conditions is not met, the authorization server will return an error message in the browser.

Submitting the state parameter is not required by the standard, but it is strongly recommended to protect against CSRF.

Step 2 – Authentication and Consent

Airlock IAM will present a login screen:

jdoe Loginapp

... and optionally ask for consent:

Authorization of a request

Step 3 – Authorization Code

If both authentication and consent grants have succeeded, Airlock IAM will redirect the browser to the redirect_uri requested that was provided in step 1. The redirect URI contains the authorization code.

Redirect URI with authorization code:

Note that with this request the authorization code is sent to the relying party (client).

Step 4 – Obtain ID, Access, and Refresh Tokens

The relying party (client) receives the authorization code and sends it to the AS to get the ID, access, and refresh tokens. Note that the following request is not sent by the browser but by the relying party.

Token endpoint request (sent by RP/client and not by the browser)
  • Content-Type: application/x-www-form-urlencoded
  • Authorization: Basic dXNlcm5hbWU6cGFzc3dvcmQ
  • grant_type=authorization_code
  • code=xRbH9uoaMMWB6urmWsg8b1xwJQF~JfD2s9CoUvwVWX42YxBwqfeC2RVWeG1Hkv
  • redirect_uri=

It is recommended to configure the authorization server, to enforce authentication on the token endpoint.

The authorization server will respond as follows:

Code Block token endpoint response

200 OK
    "access_token": "eyJraWQiOiI3YWRmMz...E9nfs7YyJZdRFP",
    "scope": "email",
    "id_token": "eyJraWQiOiI3YWRmMzgp74...Ex86vUkyMGqxQg",
    "token_type": "bearer",
    "expires_in": 17999