Flow authentication with REST UI
13.3.1.8. AS-centric AS - Flow authentication with the Loginapp REST 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 REST 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 so that the authorization code flow can be used. See 17.7.1. OAuth AS configuration - AS-centric.
Target application
The target application is configured in the flow settings of the authorization code flow or grant. See 12. Target applications and services
The target application links the authorization server with an authentication flow and identity propagation.
Authentication flow
For the authorization code flow, the authentication flow must at least contain a user identifying step and a consent step. See 12.4. 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 12.4. Identity propagation
REST UI
The authorization code flow requires an Authentication & Authorization UI for at least the user identifying and the consent steps. See 17.3. Loginapp REST 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 flow.
  • 7.
    The flow must contain a user identifying step (e.g. password step). The flow sends a response indicating that user credentials are required.
  • 8.
    The Loginapp REST 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 REST 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.
    The authorization server based on the identity propagation configuration of the target application issues the requested tokens and sends them to the client.
  • 17.
    The client sends a request to the intended resource with an access token.

Further information and links