Abstract:

This video provides a detailed guide on implementing the client side of the OAuth 2.0 Authorization Code flow using Common Lisp. It begins by defining OAuth as an access delegation protocol involving client, resource, and authorization services, focusing on the client's interaction with the authorization service (Identity Provider). The tutorial demonstrates setting up Authentik as a local, self-hostable Identity Provider, including configuring an application, obtaining client credentials (ID and secret), and defining a redirect URL. The core of the video walks through the Common Lisp client implementation, detailing the necessary web framework (Ningle) and cryptographic libraries. It meticulously explains the process of initiating the OAuth flow, including redirecting the user's browser to the Identity Provider with crucial security parameters like state, nonce, and code_challenge (for PKCE). Finally, it covers handling the callback from the Identity Provider, validating the state, and making a direct backend request to exchange the received authorization code for an access_token, successfully demonstrating token acquisition.

Exploring OAuth 2.0 Authorization Code Flow in Common Lisp

• 0:00 Understanding OAuth: OAuth is an access delegation protocol facilitating communication between client, resource, and authorization services. The client requests a token from the trusted authorization service to access resources.
• 0:41 Authorization Code Flow: The video focuses on the Authorization Code flow, the most commonly used method for clients to obtain a token, noting that while implementing an Identity Provider (IdP) is complex, client-side implementation is relatively straightforward.
• 1:09 Choosing an Identity Provider: For the demonstration, Authentik (a self-hostable IdP) is chosen, with the caveat that the process remains standard for other online providers like Google or GitHub.
• 1:31 Setting Up Authentik: The process involves creating a Common Lisp project, setting up Authentik via Docker Compose, applying migrations, and following the initial setup flow to create an application (named "CL-OAuth") and an OAuth2 provider.
• 2:58 Client Credentials and Redirect URL: The tutorial highlights obtaining the client_id and client_secret from Authentik and setting up a redirect_URL (e.g., localhost:5000/oauth/callback) which the IdP uses to return the user after authentication.
• 3:24 Common Lisp Dependencies: Essential Common Lisp libraries are introduced: Ningle (for the web service), Ironclad and Kubas-64 (for cryptographic operations related to Pixy/PKCE), and Dexador (for making HTTP requests to the IdP).
• 4:48 Implementing the Login Route: A login route is implemented in the Common Lisp application, responsible for redirecting the user's browser to the Identity Provider's authorized_URI.
• 5:34 Authorization URI Parameters: Key parameters passed to the authorized_URI are explained: client_id, redirect_uri, state (a random value stored in the session and Base64 URL encoded for authenticity), nonce (another random session-stored value for security), and code_challenge (a hash of a randomly generated code_verifier, also stored in the session, used for PKCE).
• 8:36 Implementing the OAuth Callback Route: This route (/oauth/callback) is where the user's browser is redirected by the IdP after successful authentication, carrying an authorization code and the state parameter.
• 8:55 State Verification: A crucial security step involves comparing the state received in the callback URL with the state stored in the client's session to prevent cross-site request forgery attacks.
• 9:30 Exchanging Code for Token: If the state verification passes, the client makes a direct backend-to-backend HTTP POST request to the IdP's token_URI. This request includes the client_id, client_secret, the received authorization code, the code_verifier (from the session), and the redirect_uri. The grant_type is specified as authorization_code.
• 10:33 Access Token Received: A successful exchange results in the client receiving an access_token from the IdP.
• 10:37 Future Steps: The video concludes by mentioning future work, which includes loading the access token and verifying the nonce for additional security.