/
Contact usSee pricingStart building
Node
​

    About Stytch

    Introduction
    Integration Approaches
      Full-stack overview
      Frontend (pre-built UI)
      Frontend (headless)
      Backend
    Migrations
      Migration overview
      Migrating users statically
      Migrating users dynamically
      Additional migration considerations
      Zero-downtime deployment
      Defining external IDs for users
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    DFP Protected Auth
      Overview
      Setting up DFP Protected Auth
      Handling challenges
    Magic Links
    • Email Magic Links

      • Getting started with the API
        Getting started with the SDK
        Replacing your password reset flow
        Building an invite user flow
        Add magic links to an existing auth flow
        Adding PKCE to a Magic Link flow
        Magic Link redirect routing
    • Embeddable Magic Links

      • Getting started with the API
    MFA
      Overview
      Backend integration
      Frontend integration
    Mobile Biometrics
      Overview
    M2M Authentication
      Authenticate an M2M Client
      Rotate client secrets
      Import M2M Clients from Auth0
    OAuth
    • Identity providers

      • Overview
        Provider setup
      Getting started with the API (Google)
      Add Google One Tap via the SDK
      Email address behavior
      Adding PKCE to an OAuth flow
    Connected AppsBeta
      Setting up Connected Apps
    • Integration Guides

      • Integrate with AI agents
        Integrate with MCP servers
        Integrate with CLI Apps
    • Resources

      • About Remote MCP Servers
    Passcodes
      Getting started with the API
      Getting started with the SDK
    • Toll fraud

      • What is SMS toll fraud?
        How you can prevent toll fraud
      Unsupported countries
    Passkeys & WebAuthn
    • Passkeys

      • Passkeys overview
        Set up Passkeys with the frontend SDK
    • WebAuthn

      • Getting started with the API
        Getting started with the SDK
    Passwords
      Getting started with the API
      Getting started with the SDK
      Password strength policy
    • Email verification

      • Overview
        Email verification before password creation
        Email verification after password creation
    Sessions
      How to use sessions
      Backend integrations
      Frontend integrations
      Custom claims
      Custom claim templates
      Session tokens vs JWTs
      How to use Stytch JWTs
    TOTP
      Getting started with the API
      Getting started with the SDK
    Web3
      Getting started with the API
      Getting started with the SDK

    Authorization

    Implement RBAC with metadata

    3rd Party Integrations

    Planetscale
    Supabase
    Feathery
    Unit

    Testing

    E2E testing
    Sandbox values
Get support on SlackVisit our developer forum

Contact us

Consumer Authentication

/

Guides

/

Authentication

/

DFP Protected Auth

/

Handling challenges

Handling challenges in DFP Protected Auth

DFP Protected Auth allows you to confidently screen out bad actors from your authentication through Device Fingerprinting (DFP). DFP identifies bad actors using a variety of fingerprinting techniques.

While Device Fingerprinting is always confident that BLOCK are known instances of clients obscuring their requests, the service has instances where it isn’t confident if the request is malicious and it returns a CHALLENGE verdict.

What is a challenge verdict?

A CHALLENGE verdict is an interest where our DFP product notices something that is unusual with a request. It’s not a clear indication of impersonating a user like browser automation, but instead something that our DFP product thinks is suspicious; for example, the request is from an AWS datacenter IP. As a result, how you want to handle the request depends on your risk profile.

Challenge verdicts in DFP Protected Auth

Once you turn on Enforcement mode for Protected Auth, it handles CHALLENGE verdicts by treating them as ALLOW verdicts. For increased security, you can change the Protected Auth behavior in the Stytch SDK Configuration to either BLOCK those requests or TRIGGER_RECAPTCHA on a CHALLENGE verdict.

DFP Enforcement mode

Running CAPTCHA on a CHALLENGE verdict

Stytch offers an SDK integration with Google Invisible reCAPTCHA that runs before an SDK method call. Invisible reCAPTCHA is a type of CAPTCHA that evaluates traffic without ever disrupting the user experience (hence the invisible part). When reCAPTCHA is configured and a user calls an SDK method, the SDK runs a CAPTCHA to get a captcha_token that gets forwarded with the SDK request. The Stytch backend calls the Google API on your behalf and returns an error if the reCAPTCHA doesn’t meet a threshold.

When Protected Auth is turned on Enforcement mode, the SDK won’t use reCAPTCHA by default. If CAPTCHA is configured in the Dashboard, the SDK can be configured to trigger reCAPTCHA on a CHALLENGE verdict. In this case, when Stytch receives a request with a CHALLENGE verdict, it will fail the request saying that a CAPTCHA token is required. The SDK will automatically retry the request but also include a captcha_token in the request. This allow users to have confidence that these CHALLENGE verdicts have enough friction to stop bad actors from trying to access their site.

What's next

To enable Device Fingerprinting Protected Auth, please contact support with the button below:

Contact sales

What is a challenge verdict?

Challenge verdicts in DFP Protected Auth

Running CAPTCHA on a CHALLENGE verdict

What's next