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.
- 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
- ●See 17.7.1.3. AS-centric AS - Authentication flow configuration for more information about the configuration of the authorization code flow.