Challenge

A CHALLENGE verdict is an instance where our DFP product notices something that is unusual with a request. It's not a clear indication of user impersonation like browser automation, but does indicate a lower level infraction. For example, if the request IP address matches a known AWS Datacenter IP address, we may return a CHALLENGE verdict, though that type of traffic could in some cases simply come from a VPN. As a result, how you want to handle the request depends on your risk profile and the reason for the CHALLENGE.

Some common strategies for handling CHALLENGE verdicts are:

• Allowing all requests that receive CHALLENGE verdicts to proceed.
• For sensitive applications, blocking all requests that receive CHALLENGE verdicts.

• Most commonly, requiring some additional user input (like requiring MFA or surfacing a CAPTCHA) before allowing the request to proceed.

If you'd like to definitively block or allow traffic from a specific device or group of devices that's receiving a CHALLENGE verdict, you may use the Set rule endpoint to change the verdict to either ALLOW or BLOCK for that device's identifier. Rules can also be viewed, added, removed, and modified via the Authorization rules tab within the Device Fingerprinting section of the Stytch Dashboard.

When you receive a CHALLENGE verdict in the Fingerprint lookup response, we generally recommend introducing some additional verification (such as a CAPTCHA, MFA, or other step that requires user input) to ensure that the user is legitimate before allowing them to proceed.

We return a verdict.reasons array in the Fingerprint lookup response that will indicate the reason for the CHALLENGE verdict. For example, the following response indicates that the request received a CHALLENGE verdict because it may have resulted from automatic browser traffic:

"verdict": {
	"action": "CHALLENGE",
	"detected_device_type": "UNKNOWN",
	"is_authentic_device": false,
	"reasons": ['POSSIBLE_BROWSER_AUTOMATION']
}

If you maintain your own risk score based on cumulative DFP verdicts, you should assign a medium level of risk to a CHALLENGE verdict. You may also choose to assign different risk scores to different verdict reasons. For a list of possible reasons, please contact support.

When DFP Protected Auth is enabled, the SDK will allow requests that hit CHALLENGE verdicts to proceed by default. For increased security, you can change the DFP Protected Auth behavior in your Frontend SDK configuration to either block requests that result in a CHALLENGE verdict or to trigger a CAPTCHA.

Stytch offers a JavaScript SDK integration with Google's Invisible reCAPTCHA product that runs before each SDK method call. Invisible reCAPTCHA is a type of CAPTCHA that evaluates traffic without requiring any interaction from the user. When reCAPTCHA is configured and a user calls a Stytch SDK method, the SDK retrieves a CAPTCHA token that is sent along with the SDK request. The Stytch backend calls the Google API on your behalf and returns an error if the reCAPTCHA doesn't meet the threshold that you set.

When DFP Protected Auth Challenge handling is set to Trigger CAPTCHA and a CHALLENGE verdict is returned, the SDK will trigger the CAPTCHA flow in order to add another layer of protection from malicious requests.