📒
openid-connect-workshop
  • Introduction
  • Introduction
    • Requirements and Setup
    • Sample Application Architecture
  • Intro Labs
    • Authorization Grant Flows in Action
    • Authorization Code Grant Demo
    • GitHub Client
  • Hands-On Labs
    • Resource Server
    • Client (Authorization Code Flow)
    • Client (Client Credentials Flow)
    • Testing JWT Auth&Authz
    • JWT Testing Server
    • SPA Client (Authz Code with PKCE)
  • Bonus Labs​
    • Multi-Tenant Resource Server
    • Micronaut
    • Quarkus
    • Keycloak Testcontainers
Powered by GitBook
On this page
  • Authorization code grant flow in detail
  • Run the demo application

Was this helpful?

  1. Intro Labs

Authorization Code Grant Demo

PreviousAuthorization Grant Flows in ActionNextGitHub Client

Last updated 4 years ago

Was this helpful?

A client demonstrating all steps of an Flow.

Important note: This demo client is just for demonstrating purposes. All the mandatory validations and recommended security precautions of a production-ready OAuth 2.0 client library are missing here. So do NOT use any code of this client for production !!!!

Authorization code grant flow in detail

The is the flow mostly used in today's applications adopting OAuth 2.0. It is used for resource owner authorization in many internet services like for example or .

Even for single page applications the latest best-practice drafts by the recommend using this grant (with the addition of ) instead of the .

Enterprise applications usually add on top of for implementing real authentication scenarios.

To see all details for this grant flow see the corresponding section of the .

  1. The flow starts with the authorization request, this redirects to the authorization server.

    Here the user logs in using his credentials and approves a consent page

  2. After successfully logging in a 302 HTTP redirect request with the authorization code is being sent through to the browser which redirects

    to the callback entry point provided by the client application

  3. Now the client application send a token request to the authorization server to exchange

    the authorization code into an access token.

You can see each of these steps in the demo client application of this intro lab. Usually only step 1 is visible to a user of the client. Steps 2 and 3 are only visible here to visualize the whole flow.

In addition, the demo client can also call the token introspection endpoint to verify if a token is still valid and get a new access token by using the refresh token.

Run the demo application

To start the demo:

  • Make sure Keycloak is running correctly

Important: You can use one of the following users to login:

Username

Email

Password

Role

bwayne

bruce.wayne@example.com

wayne

LIBRARY_USER

bbanner

bruce.banner@example.com

banner

LIBRARY_USER

ckent

clark.kent@example.com

kent

LIBRARY_ADMIN

You may use the username or email in the username input field.

If you remain in step 2 for a long time (where you have retrieved the authorization code) then you will get an error when proceeding to step 3 (exchanging the code for an access token). This is because the authorization code timed out.

The authorization code MUST expire shortly after it is issued to mitigate the risk of leaks. A maximum authorization code lifetime of 10 minutes is RECOMMENDED. The client MUST NOT use the authorization code more than once.

Keycloak uses a really short authorization code lifetime of 2 minutes by default.

Browse to to start the demo client

According to the :

OAuth 2.0 Authorization Code Grant
authorization code grant
SlideShare
StackOverflow
IETF
PKCE
implicit grant
OpenID Connect 1.0
OAuth 2.0
OAuth 2.0 Authorization Framework Spec
localhost:9095/client
OAuth2 specification