Sample use-case using Airlock IAM

The following page describes a sample use case intended to illustrate the requests and pages that a user observes when using Airlock IAM as both client and Authorization Server: OAuth 2.0 / OpenID Connect: Sample Use Case for the Authorization Code Grant

Detailed information on how to configure OAuth 2.0 is available here:

• OAuth AS configuration - client-centric (Marked red in the above illustration)
• Airlock IAM as client (OAuth 2.0/OIDC) (Marked grey in the above illustration)
• Detailed OAuth 2.0 SSO Configuration Sample: SSO via Google or Microsoft
• OAuth 2.0 SSO configuration example IAM to IAM (client-centric)

Two Airlock IAM instances can easily be configured to communicate via OAuth 2.0.

The configuration is straightforward since authorization server and client settings are very similar:

• Client details (id, name, secret, etc) must match in both configurations
• The redirect URL must lead to the OAuth 2.0 client servlet of the Airlock IAM client instance (<URL of Loginapp>/oauth2-client)
• By default, Airlock IAM only accepts OAuth 2.0 requests with a scope parameter. Therefore a valid scope parameter has to be supplied in the Airlock IAM client instance which must match a role of the target user. More on scopes vs roles. Alternatively empty scopes have to be allowed in the configuration.
• The security / request policies (eg. sending the redirect URL, when required) match by default, but changing a parameter might require adjustment on the other side.

This is an incomplete list of requirements that are necessary to obtain secure OAuth 2.0 setups:

• In order to ensure the security of the protocol usage of SSL/TLS is required for all communication channels including and especially for the direct communication between the client and the Authorization Server.
• The (shared) client secret should be a long and secure string and used whenever possible in the protocol messages. Otherwise, Airlock IAM is unable to verify the OAuth 2.0 client's identity, which lowers the security of the OAuth 2.0 protocol significantly.
• Airlock Gateway (WAF) Logout-Propagation should be enabled on the AS IAM mapping (pointing to /<backend-deployment-path>/logout , where <backend-deployment-path> is the path on the backend, for example auth-login) in order to allow the Authorization Server to clean-up persisted tokens once the user session runs into a timeout. Otherwise, tokens remain valid until they expire or the user explicitly terminates the session via logout call.