Passwordless authentication for your consumers

Easily create a passwordless authentication experience for your consumers using Trusona's SDKs with your backend and mobile applications.

Core implementation components

Let’s do this.

Implementing passwordless authentication for your consumers involves components from both your systems and Trusona.

  • Your components
    • Mobile application(s)
    • Backend application(s)
  • Trusona components
    • Trusona Cloud Service
    • Trusona Mobile SDK (in your mobile app)
    • Trusona Server SDK (in your backend app)

The mobile SDKs facilitate device registration, secure communication with the Trusona Cloud Service, prompts for OS biometrics, and user authentication. The server SDKs facilitate device and user registration, and user authentication.

Core implementation components

Optional implementation components

For some use cases and implementations, you may need additional components.

Trusona makes use of your existing application architecture for features like:

  • Mobile OS “deep links”
  • Push notifications
  • Certificate pinning
  • Jailbreak/Root detection

Getting started

The first step in your Trusona implementation is getting access to the Trusona service and components.

Trusona credentials

In order to interact with the Trusona service you will need two sets of credentials. These are supplied by Trusona as part of project kick-off.

  1. Server SDK token and secret
  2. Mobile SDK token and secret

Global infrastructure

You can choose a global infrastructure instance based on your performance and compliance needs.

  • North America (United States)
  • Europe (Ireland)
  • Asia (Japan)

SDK access and installation

Trusona server SDKs are open source and available on Trusona’s GitHub Repository. Trusona’s mobile SDKs are hosted on Trusona’s artifact repository. Access to the artifact repository is provided by Trusona as part of project kick-off.

You can find more details in the SDK-specific documentation.

Core implementation workflows

There are two key workflows, registration and authentication.

The registration workflow includes everything you need to get your users and their devices registered in the Trusona Cloud Service.

The authentication workflow includes different ways to authenticate your users.


The registration workflow relies on a few key terms:

  • User – The end user of your Mobile Application
  • Device – Your User’s mobile device (i.e. phone or tablet)
  • User Identifier – The unique identifier of a User in your user directory
  • Device Identifier – The unique identifier, generated by Trusona, that identifies a User’s device
  • Device and User Binding – The association between a Device Identifier and User Identifier, stored in the Trusona Cloud Service

Users and their devices must be registered in the Trusona Cloud Service. A user is considered registered when their User Identifier is bound to a Device Identifier.

Registration responsibilities

While your end user’s registration experience is heavily dependent on your own Mobile Application and specific app or use case needs, the integration with Trusona is simple and separate from the end user’s experience.

Your Mobile Application is responsible for:

  • The registration user experience
  • Interfacing with the Trusona Mobile SDK

The Trusona Mobile SDK is responsible for:

  • Generating the Device Identifier
  • Registering the Device Identifier with the Trusona Cloud Service

Your Backend Application is responsible for:

  • Finding (or creating) a User in your user directory
  • Interfacing with the Trusona Server SDK

The Trusona Server SDK is responsible for:

  • Device and User Binding

Registration steps and data flow

We can divide the registration workflow into three steps:

  1. Device Identifier creation
  2. User Identifier discovery
  3. Device and User Binding
Device Identifier creation
Device identifier creation
  1. Your Mobile Application tells the Trusona Mobile SDK to create a Device Identifier. The Trusona Mobile SDK generates public/private key pairs in the Device’s hardware key store. The Trusona Mobile SDK creates a unique identifier from one of the public/private key pairs.
  2. The Trusona Mobile SDK sends those public keys and identifier to the Trusona Cloud Service.
  3. The Trusona Cloud Service creates a new record, storing the public keys and identifier. The Trusona Mobile SDK returns the unique Device Identifier to your Mobile Application.

The User’s Device has been prepared for authentication and a unique Device Identifier has been registered with Trusona.

JWT Device Identifier

For an additional level of security, it is possible to obtain the Device Identifier in the form of a signed JWT from Trusona. This JWT can then be verified with Trusona’s JWKS service to ensure that the device identifier was generated by Trusona.

User Identifier discovery

Your specific use case will dictate how the User is identified. You may require existing Users to re-authenticate. Existing Users may make use of an existing session. New Users may use some or all of your existing registration process.

User identifier discovery
  1. An existing User authenticates with your Backend Application
  2. Your Mobile Application presents the user with the option to enable a new Passwordless authentication method
  3. The Device Identifier created earlier is now sent by your Mobile Application to your Backend Application

The Device has now been registered in the Trusona Cloud Service and a specific User has been identified in your user directory. All that’s left is to create and activate a Device and User Binding.

Hashed User Identifiers

Due to privacy or regulatory requirements, it may be necessary to use a hashed User Identifier. This hashing should take place in your Backend Application and the un-hashed value should not be shared with Trusona.

Device and User Binding

A Device and User Binding tells Trusona that there is an explicit association between a given User and Device.

Device and user binding
  1. Your Backend Application gathers the Device Identifier and User Identifier.
  2. With the identifiers, your Backend Application tells the Trusona Server SDK to create a Device and User Binding. The Trusona Server SDK sends the identifiers to the Trusona Cloud Server.
  3. The Trusona Cloud Service returns an activation code. This activation code can be used to verify the user before activating the registration.
  4. Your Backend Application tells the Trusona Server SDK to activate the newly created Device and User Binding. The Trusona Server SDK tells the Trusona Cloud Service to mark the Device and User Binding as active.

The User and their Device are registered and active in the Trusona Cloud Service.


The authentication workflow relies on a few key terms:

  • Trusonafication – The authentication challenge issued by Trusona to the User
  • OS Security – The PIN, passcode, pattern, or biometric which the user uses to unlock their device (e.g. TouchID)
  • Authentication prompt – The means by which a user signals their intent to accept or reject the authentication challenge
  • User presence – The use of OS Security that allows the user to indicate their presence during an authentication challenge

Authentication Responsibilities

The authentication workflow depends on the needs of your specific use case.

Your application is responsible for:

  • Session management
  • User authorization
  • Notifying the user of a pending authentication
  • The authentication user experience
  • Interfacing with the Trusona Server and Mobile SDKs

The Trusona Mobile SDKs is responsible for:

  • Handling incoming authentication challenges
  • Interfacing with the Device’s hardware key store
  • Interfacing with the Device’s OS Security APIs
  • Secure communication with the Trusona Cloud Service

The Trusona Server SDK is responsible for:

  • Creating authentication challenges in the Trusona Cloud Service
  • Handling in-progress authentication challenges
  • Secure communication with the Trusona Cloud Service

Authentication steps

The three common categories of authentication involve all of the core components and occur in three main steps.

  1. Creation
  2. Reception
  3. Completion

Using the Trusona Server SDK, your Backend Application creates Trusonafications in the Trusona Cloud Service. Trusonafications are created using a known User or Device Identifier and specify how the user should be authenticated.


Trusonafications are received by the Trusona Mobile SDK when your Mobile Application invokes the Trusona Mobile SDK. Your Mobile Application and the Trusona Mobile SDK are used to display and prompt the user to complete the Trusonafication.


The Trusona Mobile SDK creates a Trusonafication response, performs required cryptographic signing, and securely communicates with the Trusona Cloud Service.

Common authentication categories

Authenticating users with Trusona typically falls into one of three categories: network initiated, user initiated, and ad hoc. Although the mechanisms are similar how they are used varies.

Network initiated

Network initiated Trusonafications are used when a user is known and can be immediately authenticated. These Trusonafications are often initiated programmatically by your Backend Application. Examples include a user calling a call center or a “cookied” user returning to a web application.

User initiated

User initiated Trusonafications are used when a user is unknown and must first be identified. These Trusonafications often happen when a user is establishing a new session. Examples include a user opening your Mobile Application or logging into a web application.

User identification with Secure QR Codes

One way to identify a user in a web context (desktop or mobile) is through the use of Trusona’s Secure QR Codes. They can help your Backend Application identify a user so that a Trusonafication can be issued.

Ad hoc

Ad hoc Trusonafications are used for “step-up” authentication of a user. These Trusonafications can be performed any time with a known user. Examples include a user updating sensitive account data or initiating a risky transaction.

Shared authentication data flow

The three categories of authentication share a common data flow. This flow reflects and expands on the authentication steps outlined above.

Shared authentication flow
  1. A user tries to access a protected resource.
  2. Your Backend Application uses the Trusona Server SDK to create a Trusonafication.
  3. Optionally, your system notifies the user of the pending Trusonafication with a push notification to their Device.
  4. The User opens the app.
  5. Upon opening, the Trusona Mobile SDK is configured to fetch pending Trusonafications.
  6. The pending Trusonafication, created in step 2, is returned to your Mobile Application.
  7. Your Mobile Application along with the Trusona Mobile SDK challenge the User with the Trusonafication.
  8. The User completes the challenge and the Trusona Mobile SDK prepares the response.
  9. The Trusona Mobile SDK sends the completed Trusonafication response to the Trusona Cloud Service.
  10. The Trusona Cloud Service returns a result to your Backend Application.
  11. Your Backend Application authorizes the authenticated user.
  12. The User is granted access to the protected resource.

Get in touch

Have more questions or need additional help? Contact us.

Using custom employee identifiers in the Trusona App