Integrate online activation

During the online activation process, Mobile Authenticator Studio submits an HTTP(S) request to a web server to obtain its activation data.

Online activation (overview)

Integrating online activation involves the following steps:

1. The integrator defines the registration identifier, which will be used to identify the end user’s registration request. The registration identifier needs to be an alphanumeric string of up to 40 characters.

2. The integrator generates the authorization code, which will be used to confirm the end user’s identity during the registration request. The authorization code needs to be an alphanumeric string of up to 40 characters. The integrator needs to ensure authorization code secrecy.

3. The integrator generates the activation password, which will be used for symmetric encryption of the encrypted full activation data (XFAD). The activation password needs to be an alphanumeric string of up to 40 characters. The integrator needs to ensure activation password secrecy.

4. The integrator transmits the registration identifier, the authorization code, and the activation password to the end user in a secure manner.

5. In the Mobile Authenticator Studio app, the end user provides the registration identifier, the authorization code, and the activation password.

6. The Mobile Authenticator Studio app submits an online activation request including the identifier and the authorization code to the integrator web service.

7. The integrator back-end needs to validate the identifier as well as the authorization code for the received identifier. The integrator retrieves the corresponding authenticator data from the database.

8. The OneSpan Authentication Server Framework generates the XFAD from the authenticator data, which is encrypted according to the configured secret exchange protocol version.

9. Once the XFAD has been successfully registered, the account can be flagged as registered.

10. An online activation response including the activation data is sent to the Mobile Authenticator Studio app.

11. The Mobile Authenticator Studio app uses the activation data for activation.

12. The end user can access and work with the app.

The activation data shared between the client and the server contains the authenticator secret in the full activation data (FAD), the server time, and, optionally, the event reactivation counter (ERC).

There are two methods to encrypt the FAD and the ERC between the back-end server and the mobile application:

• The FAD and the ERC can be encrypted using the activation password and a nonce.

• The FAD and the ERC can be encrypted using a session key negotiated between the Mobile Authenticator Studio app and the back-end server.

We strongly recommend using a one-shot activation password and authorization code, especially if the same authenticator license is used to re-activate an authenticator.

Once the authenticator has been activated, the application can be configured to send an OTP to the back-end server for validation. This feature is called post-activation process.

In Online activation with post-activation (1) (overview), Mobile Authenticator Studio is pre-assigned to a specific end user. The registration identifier, activation password, authorization code, and the authenticator license are linked before any information is sent to the end user.

Online activation with post-activation (1) (overview)

In Online activation with post-activation (2) (overview), no authenticator is pre-assigned. Instead, the first available authenticator will be activated. The authenticator license is assigned after the end user has received the authenticator.

Online activation with post-activation (2) (overview)

Without pre-assignment, the user is not identified by the web server responsible for generating the activation data. Therefore, authenticator reactivation, which consists of regenerating the activation data for the same authenticator, must not be used.

The same cryptographic application can be used to generate the OTP or the derivation code that is sent in the post-activation request, and for authentication. However, there is a potential risk of code replay if the application is pure time-based response-only. In that case, it is advised to use one cryptographic application to validate the post-activation, and another cryptographic application to authenticate the user.