OAuth 2.0 target application configuration for the JSP-Loginapp

OAuth 2.0 clients are configured using identity propagators. To enable OAuth 2.0 for a specific target application set the identity propagator to "OAuth 2.0 Propagator" and fill in the required information.

It is highly important that the 'Application Entry URLs' in the target application configuration limit the allowed values of the OAuth 2.0 redirect URLs. Misconfigurations of these URL patterns (e.g. a regular expression allowing any redirect URL) may lead to token leakage and / or open redirect vulnerabilities!

The configuration of an OAuth 2.0 target application is split into several plugins:

  • The OAuth 2.0 Authorization Code Grant Identity Propagator plugin holds information about the client itself, such as:
  • Make sure that the redirect URL of the OAuth 2.0 Authorization Code Grant Identity Propagator matches only the URL pattern of this target application, since identity propagators get selected based on this URL pattern.

    • the client id (unique technical identifier used by Airlock IAM)
    • the client secret (shared secret between Airlock IAM and this target application)
    • where the client resides (redirect URL)
    • how to handle user consents
    • ...
  • The Authorization Server Settings plugin presents security options related to the OAuth 2.0 authorization server:
    • whether some OAuth 2.0 parameters may be omitted in requests
    • timeout for the authorization codes
    • timeouts for access and refresh tokens
    • the option to disable refresh tokens altogether
    • whether the issued tokens are one time use only
    • ...
  • Finally the resource endpoint responsible for settings related to accessing resources:
    • what resources may be accessed
    • what scope is required to do so
    • how the access token has to be presented in order to be accepted
    • ...

The following diagram shows the dependencies and organization of the different plugins:


Some options (especially in the Authorization Server Settings) may lower the security of the OAuth 2.0 protocol. These configurations exist in order to be compatible with non-standard-conform implementations. Only use these when required for interoperability.