This article reviews an issue that may occur where end-users are prompted to complete Multi-Factor Authentication (MFA) every time they log in, despite having recently performed MFA and/or before the re-authentication time configured in policies. This issue is accompanied by a "New Device = BAD_REQUEST" message found in system logs. 

Okta System Logs Behavior Detection will show like this:

Behaviors{New Geo-Location=NEGATIVE, New Device=BAD_REQUEST, New IP=NEGATIVE, New State=NEGATIVE, New Country=NEGATIVE, Velocity=NEGATIVE, New City=NEGATIVE}

• Multi-Factor Authentication (MFA)
• Application Sign On Policies (ASOP)
• Reauthentication time

• The Device Token is missing, set to false, or does not match the previous token.
  • When the Device Token is false or missing, the request is evaluated as BAD_REQUEST, increasing the likelihood of a high-risk score, which triggers the MFA requirement.
• A new Device Token is generated each time, indicating the token is not being properly persisted or cached.
• A Device Token is not passed correctly in the API call (must include both the Device Token cookie and Auth API token).

A BAD_REQUEST error can indicate an invalid syntax used in the request or other client-side errors, such as cache mismanagement or corruption. This can occur for several reasons, including:

• Invalid Headers: The request header might be too large or improperly formatted.
• Cache and Cookies: Corrupted cache or cookies in the browser can lead to this error.
• File Size Too Large: Attempting to upload a file that exceeds the server's size limit.
• Server Limitations: Restrictions on the length of the requested URL or the size of the request body.
• Incorrect Request Format: Passing a value in the wrong format or missing a required variable in API requests

In a scenario where this is occurring with an end-user browser:

1. Attempt to clear the browser cache and data, and reattempt authentication.
   1. It would be expected that the first login would show a behavior of New Device = POSITIVE, and subsequent attempts to show New Device = NEGATIVE.
   2. Clearing the cache and data would be expected to resolve issues where any stale cached data is causing this behavior, as the browser would need to mint fresh tokens and cached data, thus refreshing the data. 
2. Browser Settings are interfering with the browser's ability to store and access the cache.
   1. Blocking third-party cookies.
   2. Using strict tracking protection / hardened privacy settings.
   3. Disabled/Restricted Service Workers.
3. Check for Proxy or Network Middleware Interference or Browser Extensions.
   1. Some proxies or CDNs can mangle token-bearing requests (truncating headers or stripping parts), often by enforcing length limits. 
   2. Disable Browser Extensions.
4. Storage corruption.
   1. System-level logs may indicate storage issues with the hardware, which could cause data corruption or issues with reading and writing the cache.

To resolve BAD_REQUEST errors when making API calls or using and testing other programmatic configurations, admins should check the request syntax to ensure all required fields are included and correctly formatted. Additionally, clearing the cache and cookies or restarting network devices might help resolve the issue that causes BAD_REQUEST in the behavior, which can then prompt seemingly errant MFA prompts and behaviors. 

When this issue is encountered in programmatic implementation, such as making an API call with Postman, admins will need to review the RawUserAgent to send the same Device Token for every authentication request and/or make sure that "deviceToken": "[DeviceToken Value]" line is not empty, and is properly formatted. This would appear similar to:

},
"context": {
"deviceToken": "<EnsureCorrectValuesHere>"
}
}

For more detailed information on how the deviceToken should be configured in requests, review Okta's Developer Documentation on Authentication operations - deviceToken context object.

Use Primary Authentication with Trusted Application—Request Example to test and reproduce for debugging purposes using API calls in Postman. 

To count as a trusted application, be sure to include the SSWS {{apikey}} Authorization header, and:  

1. In the Postman API call, under: Authentication (Okta API) > Verify > Primary Authentication with Trusted Application.

2. This will bring up a POST to {{url}}/api/v1/authn.

3. In the Body of the request, ensure the proper content, for example:

NOTE: The Device Token may be generated randomly.

4. Hit Send and check the Okta System Logs:
   • Test 1: Behavior results in New Device = POSITIVE since this is the first time the user is logging in.
     • Behaviors{New Geo-Location=NEGATIVE, New Device=POSITIVE, New IP=NEGATIVE, New State=NEGATIVE, New Country=NEGATIVE, Velocity=NEGATIVE, New City=NEGATIVE}.
5. Hit Send again and check the Okta System Logs once more:
   • Test 2: New Device = NEGATIVE since the user is already detected.
     • Behaviors{New Geo-Location=NEGATIVE, New Device=NEGATIVE, New IP=NEGATIVE, New State=NEGATIVE, New Country=NEGATIVE, Velocity=NEGATIVE, New City=NEGATIVE}.
6. Remove or empty the values for DeviceToken and hit Send.
   • Test 3: The results now should be New Device=BAD Request.
     • Behaviors{New Geo-Location=NEGATIVE, New Device=BAD_REQUEST, New IP=NEGATIVE, New State=NEGATIVE, New Country=NEGATIVE, Velocity=NEGATIVE, New City=NEGATIVE}.

Related References

• Authentication API
• Get started with authentication
  
• Primary Authentication with Trusted Application—Request Example