Adaptive Rulesets

App developers can decide which authentication methods to register, when user authentication is necessary, and what is required to authenticate. Unfortunately, this approach means that the decision-making knowledge behind registration and authentication is hard coded.

Your organization's security policies may dictate different levels of authentication depending on the user's context. Context can include factors such as the types of authenticators that the user has already registered, the user's location, the last time they logged in, and what they're trying to do, such as checking their account balance or paying for an expensive item. Authentication should consider these factors and respond appropriately. For example:

High-risk transactions might require two-factor authentication while medium-risk transactions might only need authentication with a single factor. Low-value transactions might not need any additional authentication beyond the user of an active session clicking a button to authorize.
A user who is in a different geographical location now versus yesterday should satisfy more stringent authentication requirements.
A user who registers a weak FIDO credential that uses a software-based keystore needs to also authenticate with SMS or email OTP.
A user whose location has moved 5000 miles in the last hour has had their credentials stolen, so deny authentication.

Nok Nok's Adaptive Rulesets enable you to apply intelligent decision making to control the authentication methods that a user can register and, more importantly, customize how the user is verified based on contextual information. Adaptive Registration and Adaptive Authentication tailor their responses by evaluating data provided by your app, a small set of user history, and criteria from your organization, which is stored in the Nok Nok Authentication Server in rulesets.

Based on this information, the Server renders a decision. For registration, a decision can be:

Deny: The user isn't given the option to register.
Suggest Registration: The user can register one or more authentication methods. They can defer registration or cancel out of it.
Enforce Registration: The user registers one or more required authentication methods. They cannot use the app for other tasks until they have registered those methods.
Ignore Registration: The user cannot register any authentication methods, but this is not an error.

For authentication, a decision can be:

Deny: The user's authentication request is denied
Allow: The user is immediately authenticated without any further action
Trigger authentication: The user must verify their identity using one or more authentication methods returned with this decision.

In addition to the decision, the Server can return sets of valid authentication methods called sequences. A sequence contains all the authentication methods that are recommended or required. Unless there are extenuating circumstances, a user is expected to register all the methods in a sequence so they can authenticate in the future or use all the methods in a sequence to securely authenticate.

Sometimes you won't know a FIDO authenticator's actual characteristics until after the user has registered it or used it to authenticate. This is especially the case with FIDO2 authenticators. You can still enforce your organization's criteria at this point in the process by using a PostOperation Check in an authentication rule or a Supplemental Check in a registration decision rule.

For authentication, a PostOperation Check compares the FIDO authenticator's characteristics to your organization's guidelines for authenticators. If the comparison is true, the Authentication Server performs an action instead of continuing to process the remaining methods in the sequence. The PostOperation Check represents the extenuating circumstance mentioned earlier.

For registration, the Supplemental Check detects if the FIDO authenticator is strong. If it is, registration is complete because no other authentication methods from the sequence are needed.

For authentication, the PostOperation Check's action is one of:

Allow: Authentication is complete because the authenticator is strong
Deny: Authentication fails because the authenticator is weak
Drop sequence: Authentication with the current authentication sequence fails because the authenticator is substandard. The Authentication Server switches authentication to use methods from an alternate sequence, if one is available from the succeeding Authentication Rule.

Components of Adaptive Authentication

Adaptive Ruleset: Encapsulates your organization's criteria and guidelines that govern registration and authentication. A ruleset contains an ordered set of Adaptive Rules.

Adaptive Rule: An Adaptive Rule can be either a Registration or Authentication Rule. A Registration Decision Rule examines a set of data and decides if a user can register and what authentication methods they can register. An Authentication Rule examines a set of data and concludes whether to deny, allow, or trigger authentication. Rules contain the components listed below. The figure below shows an example of an Authentication Rule with callouts for the components.

Figure 1 Components of an Adaptive Authentication Rule

Condition: Compares context data, signals, and user history against specific values or lists of values. If a condition evaluates to true, the rule's action is triggered.
Action: The decision.
- For Registration Decision Rules, one of: deny, suggest registration, enforce registration, or ignore registration.
- For Authentication Rules, one of: allow, deny, or trigger authentication.
Sequence: When the action is suggest registration or enforce registration, the sequence is the set of authentication methods that the user should or must register so they can successfully authenticate in the future. When the action triggers authentication, the sequence defines a set of authentication methods that the user must satisfy in order to be authenticated.

An Adaptive Rule can contain multiple sequences, these represent alternative methods to register or authenticate a user's identity. You can think of sequences as being joined by OR. Registration is complete when the user has registered methods from one sequence. To successfully authenticate, the user must validate their identity with all the methods listed in one sequence.
Authentication Method: This term refers collectively to FIDO authentication, FIDO OOB (out-of-band authentication), Email OTP, SMS OTP, Selfie + Picture ID(referred to as Photo ID) and external authentication methods (e.g. passwords). You can list these methods in combinations in a sequence. You can think of methods within a sequence as being joined by AND.

PostOperation Check: Optionally added to the end of an authentication rule. For some authenticators, their specific characteristics are only known after they are used to authenticate. A PostOperation Check compares the FIDO authenticator's characteristics to desired values.

If the comparison is true, the Authentication Server performs an action instead of continuing to process the remaining methods in the sequence. The Auth Server can finish authentication because the authenticator is strong, deny authentication because the authenticator is weak, or authenticate with a different sequence because the current sequence is no longer viable.
Supplemental Check: Optionally added to the end of a registration decision rule. For some authenticators, their specific characteristics are only known after a user registers them. A Supplemental Check compares the FIDO authenticator's characteristics to desired values.

If the comparison is true, the Authentication Server performs an action instead of continuing to process the remaining methods in the sequence. The Auth Server can finish registration because the authenticator is strong, or suggest or require that the user register an additional authenticator.
Claim: A claim is a name-value pair that is used to return custom data when a rule succeeds. For example, a claim might be enable3DSBlob-true, in which case the 3DSBlob is returned when the rule succeeds. In order for the claim to be returned, a Registration Decision Rule's action must be either suggest registration or enforce registration. An Authentication Rule's action must be either allow or trigger authentication.

FIDO Policies: FIDO policies enforce your organization's choice of valid FIDO authenticators when a user registers or authenticates. You can create different FIDO policies to restrict the FIDO authenticators for specific situations. For example, you can create an Adaptive Rule that triggers when a user has a specific device model that is considered vulnerable. Your rule's sequence can use a FIDO policy to restrict the authentication method to a reliable FIDO authenticator for that model.

Data Used by Adaptive Rules

Adaptive Rules can examine a large variety of data so they can accommodate a wide range of situations. In addition, FIDO policies have optional risk rules that are applied post-authentication but before the Server returns a final verdict on the FIDO operation.

Context Data: Context data is custom information outside of Nok Nok's signals and user history that you want to factor into a registration or authentication decision. For example, by using transaction amount and type as context data, you can create rules that can enforce PSD2 compliance for low-risk, medium-risk, and high-risk transactions.

Signals: Typically data supplied by the user's device. Velocity is calculated by the Auth Server.

App SDK Version: The Nok Nok App SDK version used by your mobile or web app. You can create rules that use the version number of the App SDK since that may affect the type of data you can use in a rule's condition or approved FIDO authenticators that a user can register.
Device ID: Whether the device ID is known or not. A device ID is known after the device has completed an error-free FIDO authentication on the Nok Nok Server. Such a device ID is known even if a post-authentication risk rule denied the authentication.
Device Model: The model of the user's device.
Device Manufacturer: The manufacturer of the user's device.
Device Operating System: The operating system of the user's device.
Device Operating System Version: The operating system version of the user's device.
Device Supports Platform Authenticator: Whether or not the device supports platform authenticators.
Device Type: The type of the user's device.
IP Address: The IP address of the user's device.
Location: The user's current geographic location.
Velocity: Only used in Authentication Rules. Calculated from the user's current location, current time, their previous location, and their previous time. Determines whether the user could have reasonably traveled to their current location from their last-logged location.
WiFi Network: The WiFi network the user is connected to. You can restrict the use of your app to specific WiFi networks if your app requires a secure setting.

User History: Data stored in the Server's database. Only used in Authentication Rules.

Last Login (time): The user's last login time.
Last Login Location: The user's geographical location when they last logged in.

Risk Signals: FIDO policies support optional risk rules which assess the degree of threat indicated by a set of risk signals. Risk rules are applied by the Auth Server after a user has successfully authenticated with a FIDO method but before the final decision is sent back to the App SDK. A single rule looks at one risk signal. The risk rule can either deny registration/authentication or allow it to succeed. A rule can qualify a success response with a risk score.

The shared device and multiple device signals utilize a unique and persistent device identifier that is privacy preserving and persists across app uninstalls and reinstalls, but not across factory resets.

Device Health: Examines the device to see if it has been rooted or the OS was modified. Device health is based on the Jailbreak status which detects if a device has been altered to provide root access. Use this signal to evaluate the risk of malware and the risk of FIDO authentication being circumvented on the device.
Friendly Fraud Signal: Utilizes User Verification Set (UVS) to determine if the state of the biometric enrollments on the user’s device have changed. Allows the Server to detect when biometrics are added after a credential is registered.
Shared Device: The number of users registered on the user’s device. More users can increase risk.
Multiple Device: The number of different devices registered to the user. More devices can increase risk.

The following tables summarize the availability of signals by protocol and App SDK type.

Table 1 Availability of Signals Used in Adaptive Rules by Protocol, App SDK, and Out-of-band Authentication

NOTES on Table 1:

You must configure the App SDK to send this signal. See Configuring Signal Generation in the iOS and Android Developer Guides.
To get this signal, you must enable the IP Address plugin on the API Server.
Location is sent subject to the end user's consent. You must also configure the App SDK to send the signal. See section Sending the User Location Signal in the Nok Nok Web App SDK Developer Guide or see Configuring Signal Generation in the iOSand Android Developer Guides.
Velocity is calculated by the Auth Server based on the current location and the previous location, if available. Velocity is subject to the same requirements as location.
WiFi SSD is sent subject to the end user's consent. You must also configure the App SDK to send this signal. See section Configuring Signal Generation in the iOS and Android Developer Guides.
The web app sends the device model if the UA Parser plugin is enabled on the API Server and the user agent string contains the device model. You are more likely to get this information if the web app is running in a mobile browser.
The device type is always browser.
The web app sends the device manufacturer if the User Agent Parser plugin is enabled on the API Server and the user agent string contains the device manufacturer. You are more likely to get this information if the web app is running in a mobile browser.
The web app sends the device operating system and version if the User Agent Parser plugin is enabled on the API Server and the user agent string contains the device operating system and version. You are more likely to get this information if the web app is running in a mobile browser.
In OOB, Adaptive Rules are executed using signals from a web app running on a primary device, not the mobile app performing auth that is running on the second device. In version 5.0.0, the Android and iOS App SDKs were enhanced to support OOB in apps on the primary device, although this feature is rarely used.
"JavaScript" refers to the Web App SDK. Refer to footnotes listed in data columns for FIDO2 Web.
In App-less OOB, Adaptive Rules are executed using signals from a web app running on a primary device, not the browser performing auth that is running on the second device.

Table 2 Availability of Risk Signals used in Risk Rules by Protocol, App SDK, and out-of-band Authentication

In Table 2, you must configure the App SDK to send device health. See Configuring Signal Generation in the iOS and Android Developer Guides. Friendly fraud is not applicable for fingerprint authenticators that support automatic key deletion. In OOB, risk rules get risk signals from the mobile app that is performing authentication on the second device, not the web app running on the primary device. In App-less OOB, risk signals come from the browser performing authentication that is running on the second device.

How Adaptive Registration Works

This section provides an overview of how Adaptive Registration works using a specific decision and registration sequences as an example. Using the admin console, specify an Adaptive Ruleset for your app or use Nok Nok's default Ruleset. The figure below shows how context and signal data are sent to the Server. The Server evaluates each rule in that ruleset in order until one succeeds. In this figure, the successful Adaptive Rule contains an action of suggest registration and 3 sequences. Prior to returning the sequences, the Server filters out authentication methods that the user previously registered as well as methods not supported on the user's device.

Figure 2 Adaptive Registration Applies Rules Against Context, Signals, and User History

In this example, the Nok Nok App SDK receives the registration decision and 3 sequences from the Nok Nok Server. The App SDK presents the authentication methods from these sequences to the user and prompts them to register one. When the user selects the fingerprint authenticator to register, the App SDK interacts with the user to have them touch the sensor, as shown in the figure below.

Figure 3 The App SDK Interacts with the User to Register a Method

The user successfully registers the fingerprint authenticator. The App SDK sends the registration response and public key to the Server for validation against the FIDO policy. In this example, FIDO authentication with Fingerprint has a Supplemental Check defined for it. The Supplemental Check's condition tests the authenticator's characteristics to validate that it is a strong authenticator, its action is to finish registration. Unfortunately, this fingerprint authenticator is weak, so the user must register SMS OTP to complete the sequence.

Figure 4 The Newly-registered Authenticator Fails the Supplemental Check

The Server sends the SMS OTP method to the App SDK so the user can register it. The App SDK interacts with the user to complete registration. It prompts the user to provide a phone number and sends a passcode to the user's phone. SMS OTP registration is complete when the user enters the passcode they received in response to another prompt from the App SDK.

The user has registered both methods in a sequence so registration is now complete.

Figure 5 Registration Succeeds Because a Registration Sequence is Complete

How Adaptive Authentication Works

This section provides an overview of how Adaptive Authentication works using a specific decision and authentication sequences as an example. Using the admin console, specify an Adaptive Ruleset for your app or use Nok Nok's default Ruleset. The figure below shows how context and signal data are sent to the Server. The Server evaluates each rule in the ruleset in order until one succeeds. In this figure, the successful Adaptive Rule contains an action of trigger authentication and 3 authentication sequences. Prior to returning the sequences, the Server filters out any methods that are not applicable to the user.

Figure 6 Adaptive Authentication Applies Rules Against Context, Signals, and User History

In this example, the Nok Nok App SDK receives the authentication decision and 3 authentication sequences from the Nok Nok Server. The App SDK presents the authentication methods from these sequences to the user and prompts them to pick one. When the user selects the fingerprint authenticator, the App SDK interacts with the user to have them touch the sensor, as shown in the figure below.

Figure 7 The App SDK Interacts with the User to Authenticate with a Method

The user successfully authenticates with the fingerprint authenticator. The App SDK signs the challenge and sends it back to the Server for verification against the FIDO policy. In this example, FIDO authentication with Fingerprint has a PostOperation Check defined for it. The PostOperation Check's condition tests the authenticator's characteristics to validate that it is a strong authenticator, its action is to allow authentication. This bypasses the remaining SMS OTP method in the sequence because verifying with a strong fingerprint authenticator satisfies the requirements for strong authentication.

The Server sends back a response to the App SDK that the user is successfully authenticated. In turn, the App SDK returns this to your app.

Figure 8 The Server Verifies Whether Authentication Succeeds

Summary

These examples underscore the amount of work entailed behind the scenes to implement and execute registration and authentication. They also emphasize the benefits of using the Nok Nok App SDK. Your app only needs to make one API call and wait for the final result. The App SDK and Server do all the work to enforce your standards and interact with the user.

Adaptive Rulesets offer you these advantages:

Context-based registration and authentication that uses data from the mobile device, user history, and context data about what your user wants to do to determine the best course of action.
Registration and authentication criteria is stored in rules contained in a ruleset on the Server instead of hardcoded in your mobile or web app. As a result, any updates to Adaptive Rules are immediately available to users, rather than dependent on the user downloading and installing an updated app.
Adaptive Rules are flexible because they offer the user several registration and authentication options and require a combination of authentication methods if needed.
A Supplemental Check or a PostOperation Check is applied after a user has registered or authenticated with a FIDO authenticator. It validates that the authenticator satisfies your organization's criteria. If the criteria is met, the Authentication Server bypasses the remaining methods in the sequence.
The App SDK and the Server are powerful enough to handle all necessary user interaction during registration and authentication, greatly simplifying what your client app has to do.