Flow authentication with the Loginapp UI

OAuth 2.0 and OpenID Connect both require user authentication to take place during an authorization code grant/flow. Airlock IAM provides full integration with authentication for both the OAuth 2.0 authorization code grant and the OIDC authorization code flow.

OIDC distinguishes between client and user agent. This distinction makes it necessary that the control of the process is handed over from one actor to the next, both on the end-user device and in Airlock IAM.

Components involved in the authorization code flow

To successfully implement an authorization code flow with flow authentication and the Loginapp UI requires several configurations in Airlock IAM. The following table shows which parts of Airlock IAM need to be configured and for what purpose:

Component

Purpose

Authorization server

The authorization server must be configured to use the authorization code flow. See OAuth AS configuration.

Target application

The target application is configured in the flow settings of the authorization code flow or grant. See Target applications and services

The target application links the authorization server with an authentication flow and identity propagation.

Authentication flow

The authorization code flow must at least contain a user identifying step and a consent step. See Identity propagation

Identity propagation

Identity propagation must contain a plugin that is able to finish the authorization code flow (e.g. OAuth 2.0/OIDC ID Propagator). See Identity propagation

Loginapp UI

The authorization code flow requires an Authentication & Authorization UI for at least the user identifying and the consent steps. See Loginapp UI

Sequence Diagram

The following sequence diagram shows how client and system browser (user-agent) on one side interact with authorization server and authentication flows on the other side.

IAM_as_AS_with_REST_UI
  1. The client sends a request to the intended resource.
  2. The Gateway or Microgateway intercepts this request and fails to verify the credentials. The Gateway or Microgateway responds with not authorized.
  3. The client creates an authorization request and starts the system browser to initiate the authorization code flow.
  4. The system browser sends the authorization request to the authorization server (AS).
  5. The authorization server determines which target application and which authentication flow to start to handle this authorization request. He then sends a redirect (302) to the system browser.
  6. The system browser starts the authentication flow.
  7. The flow must contain a user-identifying step (e.g. password step). The authentication flow sends a response indicating that user credentials are required.
  8. The Loginapp UI presents the user with a login screen and sends the credentials provided by the user to the flow engine.
  9. The flow must contain a consent step. The flow sends a response indicating which consents are required.
  10. The Loginapp UI presents the user with a consent screen and sends the consent granted by the user to the flow engine.
  11. The flow processor requests an authorization response from the authorization server.
  12. The authorization server responds with an authorization response.
  13. The flow terminates and sends the authorization response to the system browser.
  14. The system browser forwards the authorization response to the client.
  15. The client uses the authorization code from the authorization response and sends it to the token endpoint of the authorization server (token exchange).
  16. Based on the target application's identity propagation configuration, the authorization server issues the requested tokens and sends them to the client.
  17. The client sends a request to the intended resource with an access token.