This article explains on a conceptual level how Airlock 2FA mobile-only authentication works. It covers both the app-to-app and the SDK usage cases.
Mobile-only authentication is sometimes also referred to as single device authentication and refers to the Airlock 2FA authentication scheme where both the business application (e.g. banking mobile app) and the Airlock 2FA authentication functions run on the same smartphone.
Mobile-only authentication uses IAM's authentication flow REST API.
All following procedures are exemplary and will vary according to your setup or needs.
Mobile-only authentication is required if the target application - the one the user is authenticated for - is on the same mobile device as the Airlock 2FA authenticating app. There are three cases:
Business app with SDK | The target application is a smartphone app (e.g. mobile banking app) and has the Airlock 2FA authentication function built into it by using Futurae's SDK. This case is described further below. |
Business app with app-to-app | The target application is a smartphone app (e.g. mobile banking app) and app-to-app communication to use the Airlock 2FA app to authenticate users. This case is described further below. |
Browser application with app-to-app | The target application is a browser application running in the smartphone's browser and app-to-app communication to use the Airlock 2FA app to authenticate users. This case is very similar to the Business app with app-to-app case and uses the same IAM REST APIs. It is not described separately below. |
Airlock 2FA also supports other types of authentication. Please inform yourself about the authentication capabilities and compare them with respect to your requirements. For further information, see Authentication factors.
The following flow chart shows how mobile-only authentication works for a business app that uses the Futurae SDK to authenticate the user.
| (1) | The user is identified using the IAM REST API. This may involve a first authentication step such as a username and password. | |
| (2) | The business app requests an authentication challenge from IAM. IAM gets the authentication challenge from the Futurae cloud. | |
| (3) | IAM returns the authentication challenge to the business app. | |
| (4) | The business app receives the authentication challenge and passes it to the Futurae SDK to handle it. The SDK access the cryptographic keys stored on the smartphones and computes the response to the challenge. | |
| (5) | The SDK sends the response directly to the Futurae cloud. The response is not sent back to IAM REST API by the business app. | |
| (6) | After the authentication challenge has been passed to the SDK, the business app may start polling for the authentication result. This is done using IAM's REST API. If the authentication process was successful, the IAM REST API provides the business app with additional information about the user (depending on the configuration). |
The following flow chart shows how mobile-only authentication works for a business app that uses app-to-app communication to authenticate users.
Additional requirements:
| (1) | The user is identified using the IAM REST API. This may involve a first authentication step such as a username and password. | |
| (2) | The business app requests an authentication challenge from IAM. IAM gets the authentication challenge from the Futurae cloud. | |
| (3) | IAM returns the authentication challenge to the business app. The challenge contains information about what app to use for authentication (URI scheme). | |
| (4) | The business app receives the authentication challenge and opens the URI in the challenge. This will cause the smartphone to open the Airlock 2FA app and pass the challenge to it (app-to-app communication). | |
| (5) | The Airlock 2FA app shows the authentication request to the user, which can approve or reject it. The result of the authentication is directly sent to the Futurae cloud and is in particular not sent back to IAM REST API by the business app. | |
| (6) | The smartphone switches back to the business app. | |
| (7) | The business app may start polling for the authentication result. This is done using IAM's REST API. If the authentication process was successful, the IAM REST API provides the business app with additional information about the user (depending on the configuration). |
The following limitations apply: