Skip to main content

Risk-based authentication and machine authentication

Use this page to understand how risk evaluation and machine authentication affect Authentication API flows.

How risk based authentication (RBA) and authentication APIs work together​

Risk-based authentication (RBA) identifies the level of risk associated with each authentication request. Once the risk level is identified, RBA defines the level of authentication required to authenticate.

An authentication request consists of three API calls:

  • Get User's Authenticators
  • Select Authenticator
  • Complete Authentication Challenge

As part of figuring out what authentications are available and required, each application's resource rule uses RBA to determine the request's risk level. The risk levels possible are low, medium, and high. The risk level of the request defines which authenticators can be used. The following factors are considered when determining the request's risk level:

  1. Date and time of request
  2. Location of request
  3. Source IP address of request origin
  4. Machine Authentication
  5. Location history of authentication requests received
  6. Travel velocity of authentication requests received

Machine Authentication​

Machine authentication is one of the factors used to evaluate each request's risk. Entrust recommends downloading the Identity as a ServiceGuard Device Fingerprint SDKs from TrustedCare for machine authentication. The SDK collects the device fingerprint and includes it as part of the machine authentication.

The risk condition generates a risk score by completing the following steps:

  1. The Identity as a Service user's Web Browser assigned the Machine Authenticator generates a machine secret. It includes these components:

    • Machine nonce: A value generated when the machine authenticator is registered and stored by the client.
    • Sequence nonce: Another value generated in a previous authentication attempt that is stored by the client. Unlike a machine nonce, the sequence nonce is modified every time an authentication API call is made.
    • Device fingerprint – A value collected from the client device.

  2. The machine secret is submitted to Identity as a Service in the query request.

  3. The machine secret is compared to machine secrets from previous authentication requests to determine a risk level.

  4. At the end of a successful authentication, a machine nonce and sequence nonce may be returned to the client. In that case, the client should store these values for future authentication attempts.

Below are example use cases for Machine Authentication:

  • Authentication from a new Web Browser that normally requires two-factor authentication. A resource rule could be configured to allow users to log by only completing a single-factor authentication if a valid Machine Authenticator is detected.
  • Authentication from a previously-used machine that normally only requires password authentication. The application's resource rule would need to be customized to support Machine Authentication. For example, a resource rule would be customized as follows to consider Machine Authentication and only require password authentication:
    • Customize the risk score assigned to users who do not have a Machine Authenticator
    • Customize the risk assigned to users who do have a Machine Authenticator
    • Set low risk authentication to PASSWORD + NONE
    • Medium risk authentication to PASSWORD + OTP