Advanced Authentication Service › Advanced Authentication Flows › Advanced Authentication Flows › Risk Evaluation-Based Flows › ArcotID OTP Roaming with Risk Flow

ArcotID OTP Roaming with Risk Flow

This section describes the authentication and risk flow for an end user who is enrolled but is using a different device to which the ArcotID OTP credential has not been provisioned.

The end user is authenticated as follows:

1. When trying to access a protected resource in a browser, the end user is prompted for the user name and OTP.
2. The end user clicks the Help icon next to the One Time Password field.

   The resulting help page provides three links to enroll for advanced authentication, reset PIN, and perform roaming authentication.

3. The end user clicks the My phone is unavailable link to perform roaming authentication.
4. On the resulting page, the end user is prompted for their user name.
5. If the user name is valid, the end user is prompted for secondary authentication using security question or security code.
6. If the user is authenticated successfully, depending on whether two-step authentication is enabled, either of the following steps takes place:
   • If two-step authentication is not enabled, an ArcotID OTP credential associated with that end user is provisioned to the web browser store, and the end user is prompted for their PIN.
   • If two-step authentication is enabled:
     1. The end user is authenticated again using another form of secondary authentication.

     Note: If security question was used the first time, then security code is used in this step. Conversely, if security code was used the first time, then security question is used in this step.

     1. If the verification is successful, an ArcotID OTP credential associated with that end user is provisioned to the web browser store, and the end user is prompted for their PIN.
7. If the PIN is correct, a JavaScript client on the end user's device implicitly generates an OTP and sends it to the Advanced Authentication service.
8. The Advanced Authentication service verifies the details and authenticates the user.
9. If authentication is successful, the Advanced Authentication service performs a risk check as follows:
   1. A JavaScript that is running in the browser does the following:
      • Checks whether a DeviceID has been recorded on the device.
      • Extracts DeviceDNA from the device to identify the device.
      • Sends this information back to the Advanced Authentication service without requiring any user inputs.
   2. The Advanced Authentication service validates the DeviceID and DeviceDNA using the configured risk rules. It then generates a risk advice.
   3. Depending on the risk advice, one of the following happens:
      • If the Advanced Authentication service returns an ALLOW advice, then the end user is granted access to the resource.
      • If the Advanced Authentication service returns an INCREASEAUTH advice, the end user is prompted for secondary authentication. If secondary authentication (described in steps 5 and 6) is successful, the end user is granted access to the resource.
      • If the Advanced Authentication service returns a DENY advice, then an error message is displayed indicating that the authentication failed.

      Notes:

      • For every time that secondary authentication is invoked in a flow, one or more secondary authentication mechanisms are exhausted. Therefore, for a flow that requires more than one round of secondary authentication, ensure that you enable as many secondary authentication mechanisms as possible. An error occurs if secondary authentication is invoked and no mechanism left.
      • If two-step authentication is enabled, and if one of the authentication methods overlaps for the roaming and risk flows, when the end user chooses that common method in the first flow and authenticates successfully, that authentication method is skipped in the next flow.

        For example, if security question or security code over email is enabled for roaming authentication, and security question or security code over SMS is enabled for risk authentication, and if the end user selects security question first and is authenticated successfully, they are not authenticated again during the risk flow. However, if the end user selects security code over email the first time and is authenticated successfully, then in the risk flow, the user is authenticated again using security question.

        In another example where security question or security code over email is enabled for roaming authentication, and security question and security code over SMS are enabled for risk authentication, if the end user selects security question in the roaming flow and is authenticated successfully, then in the risk flow, the security code over SMS method is invoked. However, if the end user selects security code over email in the roaming flow, then both security question and security code over SMS are invoked in the risk flow.

   A risk cookie is placed on the end user's device. During subsequent logins, the risk history is used to decide whether to grant access to the end user after authentication.