Forced user re-authentication

Use Case Scenario

This scenario is rather complex since it requires different parts of the authorization server to be configured correctly.

In the end, It will support the following process:

  1. The client starts an authorization code flow to obtain access and refresh token.
  3. The client obtains an SSO ticket.
  4. The client starts an authorization code flow as follows:
    1. prompt to login for forced re-authentication.
    2. acr_values set to strong-acr to force strong authentication.
    3. SSO ticket to restore the session and skip username/password verification.
  6. The user will provide a 2nd factor to complete the authentication.
  7. The client will complete the authorization code flow.

The important properties of this flow are:

  • It uses only the authorization code flow.
  • For authentication, it uses the Loginapp UI.
  • It can force re-authentication with a 2nd factor, regardless of the user's authentication.

Applications

In this scenario, we will describe a setup with 3 applications:

  1. weak-app – this app will be accessible with username/password only and not require strong authentication.
    • This app requires a one-factor authentication with username/password.
    • Is initiated with acr_values = weak-acr.
  3. strong-app – this app will be accessible using an authentication flow that requires multi-factor authentication.
    • Requires two-factor authentication with username/password and mTAN.
    • Is initiated with acr_values = strong-acr.
  5. step-up with SSO ticket – this use case is based on the use cases for weak-app and strong-app but requires additional configuration.

Use Cases

The use cases are incremental in their configuration. If you want to try this scenario in full, it is recommended to follow the use cases in order and to test each use case before proceeding to the next: