Functionality overview

  • Published on Feb 16, 2026
  • 3 minute(s) read
Prev Next

Solution features

The offline authentication solution consists of the following components:

  • An offline authentication module to support offline authentication without exposing the authenticator secret keys on the client platform.

  • OneSpan Authentication Suite Server SDK (software version).

The offline authentication module validates a one-time password (OTP) from a list of hashes. In case of successful validation, it releases an encryption key that can be used to decrypt a static secret such as the Windows password. It is secure against brute-force attacks.

The AS offline authentication solution supports event-based and time-based authenticators. The offline authentication module is available for Windows 32-bit and 64-bit platforms. It is presented as a static library (aal2off.lib) to link with C/C++ applications on the client machine.

Authentication Suite Server SDK is available for any server platform.

Only software versions of OneSpan Authentication Suite Server SDK support functionalities related to offline authentication (hash data block and state data block generation, state data block synchronization). The HSM versions of Authentication Suite Server SDK do not support offline authentication.

Processes

Five processes need to be implemented for offline authentication:

  1. Hash data synchronization between server and client

  2. State data synchronization from server to client

  3. State data synchronization from client to server

  4. Offline authentication

  5. Online authentication

The data synchronization between the server and the client and vice versa must guarantee:

  • Availability of offline authentication data (OAD) on the client side for offline authentications.

  • Code replay detection between the offline and online verification processes.

To meet these requirements, two types of data have to be synchronized between the client and the server:

  • State data. The state data contains information about the last successful authentication to detect code replay attempts and to keep track of the error counter. In the further course of this document, the state data is referred to as StateDataBlock.

  • Hash data. The hash data contains an OTP hash list that will be used to validate OTP values for offline authentication. In the further course of this document, this list will be referred to as HashDataBlock.

The authentication process(es) can be performed online or offline. The credentials for the user authentication process either consists of the user ID and OTP, or the username, a static PIN, and an OTP.

Hash data synchronization

This process involves the following steps:

  1. On the server:

    • Retrieving the authenticator application BLOB for a specific user from the server repository.

    • Generating HashDataBlock structures for a specified event window or time period.

    • Transporting the HashDataBlock structures to the client platform.

  2. On the client:

    • Storing/updating the HashDataBlock structures.

The HashDataBlock structures are generated by the Authentication Suite Server SDK function AAL2GenHashDataBlock(). Transporting, storing, and updating HashDataBlock structures is not described in this document.

The synchronization of the HashDataBlock structures from the server to the client should take place only after a successful online authentication process.

In case of static PIN support, the different HashDataBlock structures need to be regenerated whenever the static PIN is changed.

State data synchronization: Server – client

This process involves the following steps:

  1. On the server:

    • Retrieving the authenticator application BLOB for a specific user from the server repository.

    • Generating a StateDataBlock structure from the authenticator application BLOB using a new Authentication Suite Server SDK function.

    • Transporting the StateDataBlock structure to the client platform.

  2. On the client:

    • Storing/updating the StateDataBlock structure.

The StateDataBlock structure is generated by the Authentication Suite Server SDK function AAL2GetStateDataBlock(). Transporting, storing, and updating StateDataBlock structures on the client application is not described in this document.

To detect code replay, the StateDataBlock synchronization from the server to the client should take place after each online authentication process.

State data synchronization: Client – server

This process involves the following steps:

  1. On the client:

    • Retrieving the StateDataBlock structure from the local storage.

    • Transporting the StateDataBlock structure to the server.

  2. On the server:

    • Retrieving the authenticator application BLOB for this specific user from the server repository.

    • Synchronizing the authenticator application BLOB with the StateDataBlock structure using the Authentication Suite Server SDK AAL2SyncStateData() function.

    • Updating the authenticator application BLOB on the server repository.

To detect code replay, the synchronization of the StateDataBlock structures from the client to the server should precede each online authentication process.

Offline authentication

This process is executed on the client platform and involves the following steps:

  • Retrieving the StateDataBlock and HashDataBlock structures from the local storage for this specific user.

  • Calling the offline validation function with an OTP, StateDataBlock and HashDataBlock.

  • Updating the StateDataBlock structure on the local storage.

The change static PIN functionality is not available for offline authentication.

Online authentication

This process involves the following steps:

  1. On the client:

    • Transporting the OTP and user ID to the server.

  2. On the server:

    • Retrieving the authenticator application BLOB for a specific user from the server repository.

    • Validating the OTP using the Authentication Suite Server SDK AAL2VerifyPassword() function.

Summary

To detect code replay, follow these synchronization rules:

  • The synchronization of the StateDataBlock structures from the client to the server should take place prior to the first online authentication attempt.

  • The synchronization of the StateDataBlock structures from the server to the client should take place after each successful online authentication process.

With an online client, online authentication should always be the preferred authentication method.