Non-interactive OIDC authentication in IAM flows

The OIDC protocol supports the prompt=none parameter that can be used by applications (Relying Parties) to tell Airlock IAM (as OP/authorization server) not to interact with the end-user, such as showing a login page.

Instead of interactively authenticating the end-user, Airlock IAM tells the application (RP) that interactive authentication is required. The application can then decide what to do.

The feature can also be used by the application to just find out whether the end-user would have to be authenticated interactively.

Using prompt=none in IAM authentication flows

If a user needs to be authenticated, Airlock IAM starts the corresponding authentication flow – even if the prompt=none parameter was passed by the application (RP). Thus, flows must be able to handle the situation correctly, by not starting an interaction with the end-user.

To achieve this, the OpenId Connect prompt=none Condition plugin can used.

  • There are several ways to use the condition:
  • With a Message Acknowledgment Step
    Put a Message Acknowledgment Step before the first interactive step. As skip condition use the Logical NOT condition with the OpenId Connect prompt=none Condition, so the message step is skipped if no promt=none request was sent. This configuration results in the error=interaction_required HTTP parameter being sent to the application (RP) and it does not result in increasing failure counters.
    Note that if the first interactive step has skip conditions, you need to also use them in the Message Acknowledge Step (using Logical OR) and you need to put another Message Acknowledge Step before the next (possible) interactive step.
  • With an AbortStep
    The same as with the Message Acknowledge Step above but using the Abort Step. This configuration results in the error=access_denied HTTP parameter being sent to the application (RP).
  • As Precondition (not recommended)
    Negated with the Logical NOT condition, the OpenId Connect prompt=none Condition can be used as a precondition to the first interactive step. The flow will then fail before the interaction takes place but it also increases the failed login counters of the step with the precondition. This may not be desired.