REST interaction model

The REST interaction model is based on Loginapp REST API and suitable REST clients such as mobile applications.

This interaction model requires that the REST client knows how to react to responses of the REST API.

Note that the Loginapp REST API is also used for modern web applications (such as the Loginapp UI).

The REST API provides additional end-points supporting the Redirect Authentication Flow of the Airlock Gateway. These calls are not shown in the sequence diagram below but listed here: Loginapp UI configuration for authentication and authorization flows.

Properties of the example

  • Authentication
  • The session in the application is tracked with an authorization header with a JWT.
  • The back-ends use session cookies or an authorization header with a JWT to track the user.

Sequence diagram

  • Used colors
  • Yellow: external view
  • Green: internal view

Both views are independent and can use different methods for session tracking, identity propagation, etc.

Airlock Gateway translates the external session to the internal session used by the back-end applications. No session information from the back-end is sent to the client.


  1. Unauthenticated access to back-end:
    • First, the Airlock Gateway checks the request and applies the configured filter rules.
    • It then checks the required roles in the mapping configuration.
    • If the user does not have the required roles, a 401 Access Denied response is returned to the REST client.
    • The REST client now calls the authentication REST end-points to authenticate the user. It either directly calls the shown access end-point corresponding to the requested application or it uses a different end-point to learn about the access end-point to call (not shown in the diagram, see Loginapp UI configuration for authentication and authorization flows).
  2. Login on Airlock IAM:
    • The login is performed on Airlock IAM with username, password, and a 2nd factor.
    • Once the login is successful, Airlock IAM issues a JWT for identity propagation and sets a new Gateway role
    • The JWT and the role are stored in the Gateway session store.
  3. Authenticated access eith JWT:
    • The user can now access the back-end application.
    • In the first call, the back-end application extracts the user id from the JWT.
    • In subsequent calls, it can either again use the JWT or rely on information stored in the session.
    • Application-specific access decisions are taken in the back-end application.