Airlock 2FA Recovery Trusted Session Binding Step
This step can be used to recover previously enrolled Airlock 2FA accounts on a fresh installation of a mobile app. This refers to mobile apps which integrate the Futurae SDK and can therefore be enrolled as a device for an Airlock 2FA account. An enrollment of an Airlock 2FA account on a mobile app is subsequently referred to as a (virtual) device. One physical device can host multiple virtual devices. If 'Trusted Session Binding for Recovery' is enabled in the 'Airlock 2FA Settings', this step is necessary for users to recover their devices.
Airlock IAM does not provide a UI for this step, since it exposes a REST API which is intended to be used by custom mobile apps.
The following describes the recovery use case which is enabled by this step:
- A fresh installation of a mobile app extracts the device identifiers of a previous installation from a backup.
- A user authenticates with Airlock IAM (via the mobile app).
- This is where the 'Airlock 2FA Recovery Trusted Session Binding Step' has to be active in the IAM flow. The step can be completed successfully with the following actions:
- The mobile app sends the device identifiers Airlock IAM.
- Airlock IAM checks whether one of the devices to be recovered belongs to the authenticated user and aborts the flow otherwise.
- Airlock IAM requests a Trusted Session Binding token from Futurae and returns it to the mobile app. If Airlock IAM does not receive a flow binding token from Futurae, it will return an empty response and the step will continue as if the retrieval was successful.
- The mobile app forwards the Trusted Session Binding token to the Futurae SDK to complete the recovery.
- The mobile app polls Airlock IAM for the status of the recovery.
- After successful recovery, all users who had devices on the previous installation will have new devices and the ones from the previous installation cannot be used anymore.
airlock2faSettings) authenticationMethodId) Example: a system tracks two passwords per user. Password 1 is used in flow A, password 2 in flow B. These two steps must have distinct 'Authentication Method Ids', e.g. PASSWORD1 and PASSWORD2.
If only one identifier (e.g. "PASSWORD") is used, this may allow brute force attacks on the password as follows. Assuming an attacker knows the user's password 1, they get an unlimited number of attempts on flow B, as the 'PASSWORD' counter can repeatedly be reset to 0 by performing a successful login on flow A.To prevent such attacks, use two different counters by setting the authentication methods, for example, to PASSWORD1 and PASSWORD2, respectively.
interactiveGotoTargets) dynamicStepActivations) skipCondition) If this condition is configured and fulfilled, the step is skipped and the flow execution continues with the subsequent step.
preCondition) requiresActivation) tagsOnSuccess) stepId) onFailureGotos) If the step fails (no retry) and a goto target for the error code is defined here, the flow does not fail and instead a "goto" to the specified target step is executed. Note that even when the "goto" is executed, any error codes that are considered a failed factor attempt will still increment the "failed attempts" counter, and may lead to the user being locked. Therefore, this may still result in a failed flow.
A typical application of this feature is switching to an alternative authentication factor step, if an external service (e.g. Futurae server, SMS gateway) is not available (error code EXTERNAL_SERVICE_UNAVAILABLE with "Strict Counting" disabled, which will not increment the "failed attempts" counter). Other error codes can be found in the IAM REST documentation, in both the general "Error Codes" section and in the documentation of specific endpoints.
customResponseAttributes) A list of custom attributes that are returned in the REST response in addition to the standard attributes the step already returns. The custom attributes defined here are only returned if the step result does not lead to an error response.
Custom attributes are added to the response when a step is initialized and when actions are executed on the step. They will therefore be available in the response leading to this step, and in any responses from endpoints specific to this step. For non-interactive steps, custom attributes are accumulated and added to the response leading to the next interactive step.
Custom attributes are not returned for 'retrieve' endpoints.
customFailureResponseAttributes)
type: Airlock2faRecoveryTrustedSessionBindingStep
id: Airlock2faRecoveryTrustedSessionBindingStep-xxxxxx
displayName:
comment:
properties:
airlock2faSettings:
authenticationMethodId: AIRLOCK_2FA
customFailureResponseAttributes:
customResponseAttributes:
dynamicStepActivations:
interactiveGotoTargets:
onFailureGotos:
preCondition:
requiresActivation: false
skipCondition:
stepId:
tagsOnSuccess: