/
Contact usSee pricingStart building

    About B2B Saas Authentication

    Introduction
    Stytch B2B Basics
    Integration Approaches
      Full-stack overview
      Frontend (pre-built UI)
      Frontend (headless)
      Backend
    Next.js
      Routing
      Authentication
      Sessions
    Migrations
      Overview
      Reconciling data models
      Migrating user data
      Additional migration considerations
      Zero-downtime deployment
      Defining external IDs for members
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    Single Sign On
    • Resources

      • Overview
        External SSO Connections
        Standalone SSO
    • Integration Guides

      • Start here
        Backend integration guide
        Headless integration guide
        Pre-built UI integration guide
    OAuth
    • Resources

      • Overview
        Authentication flows
        Identity providers
        Google One Tap
        Provider setup
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Connected AppsBeta
      Setting up Connected Apps
      About Remote MCP Servers
    • Resources

      • Integrate with AI agents
        Integrate with a remote MCP server
    Sessions
    • Resources

      • Overview
        JWTs vs Session Tokens
        How to use Stytch JWTs
        Custom Claims
    • Integration Guides

      • Start here
        Backend integration
        Frontend integration
    Email OTP
      Overview
    Magic Links
    • Resources

      • Overview
        Email Security Scanner Protections
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Multi-Factor Authentication
    • Resources

      • Overview
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
        Pre-built UI frontend integration
    Passwords
      Overview
      Strength policies
    UI components
      Overview
      Implement the Discovery flow
      Implement the Organization flow
    DFP Protected Auth
      Overview
      Setting up DFP Protected Auth
      Handling challenges
    M2M Authentication
      Authenticate an M2M Client
      Rotate client secrets
      Import M2M Clients from Auth0

    Authorization & Provisioning

    RBAC
    • Resources

      • Overview
        Stytch Resources & Roles
        Role assignment
    • Integration Guides

      • Start here
        Backend integration
        Headless frontend integration
    SCIM
    • Resources

      • Overview
        Supported actions
    • Integration Guides

      • Using Okta
        Using Microsoft Entra
    Organizations
      Managing org settings
      JIT Provisioning

    Testing

    E2E testing
    Sandbox values
Get support on SlackVisit our developer forum

Contact us

B2B Saas 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 Decisioning Mode for Bot Protected Auth, it handles CHALLENGE verdicts by treating them as ALLOW verdicts. For increased security, you can change the Bot Protected Auth behavior in the Stytch SDK Configuration to either BLOCK those requests or TRIGGER_RECAPTCHA on a CHALLENGE verdict.

DFP Decisioning mode

Running Recaptcha on a CHALLENGE verdict

Stytch offers an SDK integration with Google’s 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 Bot Protection is turned on decisioning mode, the SDK won’t use Recaptchas by default. If a ReCaptcha is configured in the Dashboard, the SDK can be configured to trigger a 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 Recaptcha on a CHALLENGE verdict

What's next