Airlock 2FA Trusted Session Binding

​​​​​

The Airlock 2FA Trusted Session Binding feature is a security feature that makes token enrollment and app recovery more secure by binding these actions to an IAM authentication flow or a protected self-service flow.

Prerequisites

  • To use the Trusted Session Binding the following requirements must be met:
  • The feature is for custom mobile apps (e.g. e-banking apps) using the Futurae SDK only.
  • The standard Airlock 2FA app does not support the feature.
  • Existing custom apps must be adapted to use the feature.
  • The feature requires a special Airlock 2FA license bundle. Please contact order@airlock.com for further details.

Motivation

  • There are critical Airlock 2FA-related workflows in which Airlock IAM is not directly involved. These include
  • token enrollment via letter (scan QR code from a printed letter)
  • app recovery (from cloud backup)

Depending on the security requirements and threat model, this may be fine. Where this is not enough, the Trusted Session Binding feature helps further increase security: It allows binding the action (enrollment or recovery) to an IAM flow and may thus guarantee that the action can only be taken by a legitimate end-user.

Example: Scanning an enrollment QR code from a letter may be bound to a flow in which the user must enter the correct username and password. This guarantees that the letter is only used by the legitimate user.

Example: The recovery of an authentication app (e.g. for a new phone) from a cloud backup may be bound to a flow in which the user must enter the correct username and password. This guarantees that the recovery process is initiated by a legitimate user.

Overview

To ensure that the action (enrollment or recovery) is only possible after successfully passing an authentication flow, a so-called binding token is sent from Airlock IAM to the mobile app. The binding token is only sent to the mobile app if the configured authentication flow is passed and if the enrollment or recovery is verified to be for the legitimate user.

The mobile app uses the binding token when using the Futurae SDK to perform the enrollment or recovery. The Futurae service verifies the binding token and denies the action if the binding token is not valid or missing.

Consider the following flow diagram depicting the enrollment (activation) of an app with a QR-code letter using the Trusted Session Binding feature.

TrustedSessionBindingWithEnrollment

(1)

An enrollment QR code letter is generated and sent to the user.

(2)

Within the enrollment process of the business app (e.g. e-banking app) the IAM Auth API is called to authenticate the user. This may be, for example, a username/password check.

(3)

Airlock IAM authenticates the user and keeps the user's identity in the session.

(4)

The user scans the enrollment code from the letter in the business app. The business app sends the enrollment code to Airlock IAM.

(5)

Airlock IAM verifies that the enrollment code was originally issued for the user just authenticated. If so, it gets a binding token from the Futurae cloud.

(6)

Airlock IAM sends the binding token to the business app which calls the SDK with the binding token (and the enrollment code).

(7)

The SDK in the business app sends the binding token together with the enrollment code to the Futurae cloud. The Futurae cloud verifies that the binding token is valid and completes the enrollment of the app.

Configuration

  • The Trusted Session Binding feature can be enabled for enrollment (activation) and/or recovery in the Airlock 2FA Settings.
  • Depending on the use case, either an authentication flow or a protected self-service flow must be set up, and a corresponding flow step must be included. The use case examples below show what steps to use.

Use case 1: Recovery (Flow steps and REST call sequence)

The recovery process allows to restore previously enrolled Airlock 2FA accounts on a fresh installation of a mobile app, e.g., when using a new mobile phone.

Note that a physical device may contain multiple Airlock 2FA user accounts. All of them are recovered at a time, i.e., if one of the accounts to be recovered belongs to the legitimate user, a binding token is issued and the recovery process for all accounts succeeds.

If Trusted Session Binding for Recovery is enabled in the Airlock 2FA Settings use the step Airlock 2FA Recovery Trusted Session Binding Step in the authentication or protected self-service flow as indicated in the subsequent examples:

  • Example 1: Authentication flow
    • Flow steps:
    • Username Password Authentication Step
    • Airlock 2FA Recovery Trusted Session Binding Step
    • REST endpoints to call:
    • /rest/public/authentication/password/check/
    • /rest/public/authentication/airlock-2fa/recovery/start/
    • /rest/public/authentication/airlock-2fa/recovery/status/poll/

Please refer to the step's plugin documentation in the Config Editor for more information.

Details on the mentioned REST API endpoints can be found in the REST API specification: Loginapp REST API Reference

  • Example 2: Protected self-service flow
    • Flow steps:
    • Airlock 2FA Recovery Trusted Session Binding Step
    • REST endpoints to call:
    • /rest/protected/self-service/airlock-2fa/recovery/start/
    • /rest/protected/self-service/airlock-2fa/recovery/status/poll/

Use case 2: Enrollment/Activation with letter (Flow steps and REST call sequence)

If a QR code enrollment letter has been sent to the user, use the step Airlock 2FA Activation Trusted Session Binding Step to secure the process with the Trusted Flow Binding feature.

In the Airlock 2FA Settings, make sure that Trusted Session Binding for Activation is either set to Only with Letter or to Always.

  • Example 3: Authentication flow
    • Flow steps:
    • Username Password Authentication Step
    • Airlock 2FA Activation Trusted Session Binding Step
    • REST endpoints to call:
    • /rest/public/authentication/password/check/
    • /rest/public/authentication/airlock-2fa/activation/start/
    • /rest/public/authentication/airlock-2fa/activation/status/poll/

Please refer to the step's plugin documentation in the Config Editor for more information.

Details on the mentioned REST API endpoints can be found in the REST API specification: Loginapp REST API Reference

  • Example 4: Protected self-service flow:
    • Flow steps:
    • Airlock 2FA Activation Trusted Session Binding Step
    • REST endpoints to call:
    • /rest/protected/self-service/airlock-2fa/activation/start/
    • /rest/protected/self-service/airlock-2fa/activation/status/poll/