Mobile integration process

Goal

The aim of this tutorial is to lay out the steps for integrating TypingDNA Authentication API for mobile applications.

Intro

User identity verification using TypingDNA Authentication API can be integrated on mobile devices as part of native apps or mobile browser web apps.

Terminology

Typing pattern: user typing behaviour data
Typing pattern enrollment: attach and save a typing pattern to a user
Typing pattern verification: check that the current typing pattern matches those attached to a particular user
Recording typing pattern: capture user typing patterns through a client library

Mobile typing patterns

We call the user typing behavior a typing pattern. The terminology is used regardless of the platform on which the integration is implemented. See more info regarding typing patterns here.

By default, a typing pattern consists of keystroke data (i.e., timings based on keydown and keyup events). But, on mobile devices, typing patterns can also contain motion data (e.g., acceleration and orientation) as we will see below. For more information, check out our typing pattern viewer tool here.

Typing patterns that also contain motion data are considered more robust. This is because they capture the typing behavior of the user more comprehensively.

Mobile typing patterns are different from desktop typing patterns. This means that a user has to be enrolled from a mobile device (hence with a mobile typing pattern) to be able to further authenticate themselves on mobile devices.

Moreover, mobile typing patterns differ based on the position of the typing (check mobile positions documentation here). This is very important because a user can be validated only on a typing pattern position that was used during enrollment. To exemplify, some mobile typing positions are: typing while holding the phone in your hand in portrait orientation (used most often), typing while holding the phone on a surface (i.e., a desk) in portrait orientation, and typing in landscape orientation.

Mobile browser vs. native implementations

Here are some considerations to keep in mind before deciding to implement TypingDNA Authentication API inside a native app and a mobile browser web app:

All native implementations generate typing patterns that also contain motion data (as explained in Mobile typing patterns section); thus, it is recommended to opt for a native app integration for best results.
Currently, Android browser app integrations generate typing patterns with motion data, but iOS ones do not (since version 12.2).

Native integration process

Since the goal is authenticating mobile users based on their typing patterns, there are two main steps that need to be accomplished:

Recording the user’s typing pattern
Using the recorded pattern to register, enroll, or authenticate the user

The first step above is done by using one of our native recorder libraries on Android or iOS. You can find documentation on how to use these libraries in their respective GitHub repositories.

The second step consists of making API calls to our API Authentication Service. To do that, you need to have a TypingDNA account that comes with the authentication keys needed to make the API calls (sign up here).

We recommend creating proprietary calls from your mobile app to some back-end service on your side, which, in turn, makes the calls to TypingDNA’s Authentication API. It is a good practice to keep the API connection keys in a safe place (on your back-end).

Mobile browser integration process

You can have a web app that integrates with the TypingDNA JS Recorder and will also work for mobile browsers. However, to be able to implement the specific mobile workflow, you can make use of TypingDNA.isMobile() recorder method to check if the current running environment is mobile or not.

Authentication Workflow

The authentication workflow is the same as the one for the web with the following difference(s):

If a user has previously enrolled typing patterns from a mobile device and verification is attempted on a new typing pattern that is recorded for another mobile position than those which are already enrolled, then, as per the Authentication API Documentation, a message code 3 (i.e., “No previous patterns enrolled with this typing position.”) is received from the API. In this case, the user cannot be authenticated with the provided typing pattern.
To get around this, you can employ the passive enrollment technique. This enables you to enroll a new pattern with the new mobile position so that the user can also be authenticated on the current mobile position in the future. To make sure it comes from the right user, we suggest you validate his/her identity with a second factor (e.g., a one-time-password delivered via SMS).