Passwordless authentication, without an app, for your consumers

Easily create a passwordless authentication experience for your consumers, without the need of a custom mobile app, using Trusona's SDKs with your backend and mobile browser.

Updated May 7, 2021

Core implementation components

Let’s do this.

Implementing mobile auth for browsers for your consumers involves components from both your systems and Trusona.

Your components:

• Web application(s)
• Mobile web browser(s)

Trusona’s components:

• Trusona Cloud Service
• Trusona Web SDK

Getting started

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

Trusona credentials and configuration

In order to interact with the Trusona service, you will need credentials for the access. These are supplied by Trusona as part of project kick-off. During the kick-off, we will also set up the configuration for your domain. This will involve setting up a CNAME record in your DNS so that the FIDO credentials, used during authentication, are scoped to your domain origin, and not Trusona’s.

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 Web SDK is open source and available on Trusona’s GitHub Repository.

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.

Registration

The registration workflow relies on a few key terms:

• User – The end user of your web applications from a mobile browser
• Mobile platform authenticator – Your User’s FIDO/Webauthn capable mobile device (i.e. phone or tablet)
• User Identifier – The unique identifier of a User in your web application 

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

Registration responsibilities

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

Your Web Application is responsible for:

• The registration user experience (e.g. User sign up flow on your Web Application)
• Finding (or creating) a User in your user directory
• Interfacing with the Trusona Web SDK
• Interfacing with the Trusona Cloud Service

The Trusona Web SDK is responsible for:

• Displaying a QR, representing the unique URL, to the User, if desired

Your Trusona Cloud Service is responsible for:

• Providing a unique URL for the registration
• Mobile Platform Authenticator registration
• Maintaining the relationship between the Mobile Platform Authenticator and the User Identifier

Registration steps

Mobile auth for browsers registration steps

We can divide the registration workflow into these steps:

1. User signs up, or authenticates, with your Web Application, establishing a known User and their User Identifier. This step is entirely owned by your application and flows.
2. Your Web Application initiates a registration with the Trusona Cloud Service.
3. Trusona Cloud Service returns a registration URL. You can use your own methods to present this to the User, use the SMS method by Trusona (see step 4) or use the QR method provided by Trusona (see steps 5-6).
4. Optionally, a User’s phone number can be provided in step 2, which will be used to send an SMS to the Mobile Platform Authenticator containing the registration URL.
5. Optionally, your Web Application uses the Trusona Web SDK to display a QR of the registration URL for the User to scan with their Mobile Platform Authenticator.
6. Optionally, User scans the QR using their Mobile Platform Authenticator’s QR scanner (e.g. the phone’s camera app).
7. The Mobile Platform Authenticator opens the registration URL (provided by SMS, QR code, or your method) and the User is prompted to complete the registration.
8. The Mobile Platform Authenticator’s attestation is provided to the Trusona Cloud Service.

The User’s Mobile Platform Authenticator has now been prepared for authentication.

Authentication

The authentication workflow relies on a few key terms:

• Challenge
• OS Security
• Challenge prompt

Authentication responsibilities

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

Your Web Application is responsible for:

• Session management
• User authorization
• Priming before and after the authentication
• Presenting the authentication URL to the Mobile Platform Authenticator
• Interfacing with the Trusona Web SDK and Trusona Cloud Service

The Trusona Web SDK is responsible for:

• Displaying a QR, representing the unique URL, to the User, if desired

The Trusona Cloud Service is responsible for:

• Providing a authentication (login) URL for the authentication
• Invoking a callback when authentication is complete
• Validating the challenge’s response

Authentication steps

Mobile auth for browsers authentication steps

We can divide the authentication workflow into the following steps:

1. Your Web Application requests an authentication challenge with a callback URL (Optionally, the callback can be omitted, which will necessitate step 10).
2. Optionally, meta-data can be supplied that can be displayed as part of step 7.
3. An authentication URL is returned.
4. The authentication URL is sent to the Mobile Platform Authenticator (e.g. you can choose to present a QR code, send an SMS, or other method of your choice).
5. Optionally, the Trusona SDK can be used to render a QR for the authentication URL.
6. The Mobile Platform Authenticator opens the authentication URL (provided by SMS, QR code, or your method).
7. The authentication challenge is returned to the Mobile Platform Authenticator. If the optional meta-data is supplied in step 2, it will be displayed as part of the challenge.
8. The Mobile Platform Authenticator receives the challenge and invokes the local Webauthn API.
9. The authentication response is presented to Trusona Cloud Service.
10. Optionally, your Web Application requests the authentication status from the Trusona Cloud Service.
11. The Trusona Cloud Service returns the authentication response status. This will use the callback URL, if specified in step 1.

Get in touch

Have more questions or need additional help? Contact us.

---