This article clarifies the meaning of the BAD_REQUEST entry when it appears within the Behaviors section of a System Log event. It explains why this specific behavior is flagged and provides steps to identify and resolve the underlying cause.

• System Logs 

• X-Device-Fingerprint Header

• Okta Classic Engine

The string BAD_REQUEST appears in the Behaviors section of a log event when the device fingerprint is missing from the incoming request.

A device fingerprint is typically sent via the X-Device-Fingerprint header. Okta relies on this fingerprint for device trust and security context. This behavior is triggered by:

• A lack of effective communication between Okta and the specific device, or the X-Device-Fingerprint header is being stripped before it reaches Okta.
• Requests originating from jailbroken or rooted mobile devices (though not all). These modifications can prevent the device from generating or sending the required fingerprint.

To resolve the BAD_REQUEST behavior, ensure that the device fingerprint is successfully generated and transmitted for the requests in question.

1. Identify the Behavior in System Logs

   1. Navigate to Reports > System Log.

   2. Expand the relevant event entry.

   3. Look specifically at the Behaviors section (often found under DebugContext or System details, depending on the view). Confirm that BAD_REQUEST is listed.

   4. Look specifically for a key-value pair where the value is BAD_REQUEST, such as:

      • New Device = BAD_REQUEST

      • New City = BAD_REQUEST

2. Verify the X-Device-Fingerprint Header

   1. Ensure the client application or browser is generating the X-Device-Fingerprint header.

   2. If a custom integration is used, verify that the code is correctly implementing the device fingerprint generation SDK or logic.

3. Investigate Network Intermediaries

   1. Check any proxies, firewalls, or load balancers sitting between the user and Okta.

   2. Ensure these devices are not configured to strip unknown headers, or specifically, the X-Device-Fingerprint header.

4. Assess Device Compliance

• • If the logs indicate this behavior is coming from mobile devices, check the device status.
  • If the device is jailbroken or rooted, the missing fingerprint is often expected behavior. It may be necessary to review the organization's policy regarding support for modified operating systems.

Related References

• Primary authentication with device fingerprinting