Mobile-only auth (app-to-app / SDK)
10.2.2.2.4. Mobile-only authentication (app-to-app or SDK)

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.

Goal

  • Understand mobile-only authentication in general.
  • Understand the differences between SDK-usage and app-to-app.
  • Understand the interaction between involved components.
  • Learn details about prerequisites and limitations.

All following procedures are exemplary and will vary according to your setup or needs.

Initial thoughts

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 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 10.2.2.2. Authentication factors.

Prerequisites

  • User account exists in IAM.
  • The user has Airlock 2FA enabled as a possible authentication method.
  • The REST authentication flow is configured to support mobile-only authentication.
  • The user's smartphone is connected to the internet and is able to connect to the Futurae cloud.
  • The business app has enrolled an Airlock 2FA factor.

Mobile-only authentication for business app with SDK

The following flow chart shows how mobile-only authentication works for a business app that uses the Futurae SDK to authenticate the user.

UC-MobileOnly-SDK-DrawIO_en-us
(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).

Mobile-only authentication for business app using app-to-app

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:

  • The user has installed the Airlock 2FA app on the smartphone.
UC-MobileOnly-ApptoApp
(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)
After the authentication challenge has been passed to the Airlock 2FA app, 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).

Limitations

The following limitations apply:

  • The IAM Loginapp web interfaces do not support browser applications with app-to-app communication. This applies to IAM version 7.6 and might be improved in future versions. However, the IAM REST API provides the necessary functions. Thus, a custom login front-end may implement the use-case.