Skip to main content
Version: 7.2402.x.x RR

UC01 - Adaptive authentication

One of the main use cases of nevisAdapt is adaptive authentication. The purpose of adaptive authentication is to add further layers of security when logging in by taking the details of the authentication context into consideration on top of the direct authentication input, such as username and password.

Authentication context​

When a user tries to log in, they usually have to provide authentication input. These most common forms of these are username / password, occasionally One-Time-Password / CAPTCHA, these answer the questions: What do I know? Am I human?.

Next to these, other forms of data are also shared (IP address / device cookie / browser fingerprint) of the user at the moment of the authentication attempt. These answer the questions: Where am I? What is my reputation? What do I use?. Keeping track of these values and comparing them to the current attempt can answer further questions, for example, How fast am I?. This data together forms the authentication context.

Another option to separate authentication flows is identifying events or combinations of events, for example, new geolocation for the user and/or blacklisted IP address.

Authentication flow​

The direct integration of nevisAdapt into the authentication workflow (nevisAuth) is done via NevisAdaptAuthState. The entries below give an overview of the two options for its usage, for further details (for example, profiles and default weights), see the corresponding page. The purpose of both is to find some way to determine, which authentication step (if any) follows the one invoking the nevisAdapt service. The service returns a list of events and the overall risk score.

Risk-based authentication flow​

This mode is the default behavior for the AuthState.

The more recurring elements are found in the authentication context data during a login attempt, the more likely that the holder of the account was the one who entered those credentials, which means lower risk score. If any of the context data is brand new, it increases the overall risk score. There are two thresholds defined: medium and high risk, each of them can lead to a different authentication flow (on top of the default no/low risk authentication path).

The various risk events are assigned a weight, which determines how much they contribute to the overall risk score. The combination of risk weights and thresholds are called risk profiles. There are two default risk profiles available: strict and balanced. There is also a third option (custom), which allows free allocation of weights and thresholds, but you should contact your Nevis representative first if you wish to introduce your own risk profile.

If no explicit timeout step is configured, the authentication step assumes the highest risk threshold that is available.

Event-based authentication flow​

This mode is the alternative behavior for the AuthState.

An alternative option to separate authentication flows is identifying events or combinations of events, for example, new geolocation for the user and/or blacklisted IP address. In this case no individual/overall risk scores are taken into consideration, only the pre-configured priority order of the combinations to match against. If the login attempt matches an entry in the list, the remaining entries are not checked. If no combination matches, it will assume that it is OK to pass.

As there are no risk score thresholds available, setting an authentication follow-up step in case of timeout is mandatory.

Installation​

For the on-prem installation process, see Installation of nevisAdapt.

nevisAdmin 4 deployment​

There are two main compositions of nevisAdmin 4 patterns, one for each main use case, this one is a direct integration into nevisAuth that implements adaptive authentication.