/
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

/

Setting up DFP Protected Auth

Getting started with DFP Protected Auth

Stytch Protected Auth is a frontend SDK feature that utilizes Device Fingerprinting to ensure that only legitimate users can access your auth flows. We offer support across our Javascript, iOS, and Android SDKs.

In this guide, you'll learn how to set up DFP Protected Auth. By the end, you'll have:

  • Installed the frontend SDK.
  • Turned on Observation mode.
  • Turn on Enforcement mode.

If you haven't already, check out this high-level overview of DFP Protected Auth.

Before you start

In order to complete this guide, you'll need the following:

  • A Stytch project (either Consumer or B2B). If you don't have one already, in the Dashboard, click on your existing project name in the top left corner of the Dashboard, click Create a new project, and then select B2B Authentication or Consumer Authentication.
  • The project_id and secret for the Test environment you would like to use. These values can be accessed from the API keys section of the Stytch dashboard. You'll need to pass these values into the Authorization request header for most Stytch API calls.
  • Device Fingerprinting enabled. If you don't have these product enabled, reach out to Stytch here.

Step 1: Install the frontend auth SDK

Since DFP Protected Auth is built on top of our frontend authentication SDKs, you need to install and use one of the SDKs before you can enable DFP Protected Auth.

Stytch offers multiple starting guides and example apps that you can use to build the authentication flows. Here are a few guides you can use as a starting point:

  • Email Magic Links for Consumer Auth
  • Passwords for Consumer Auth
  • Example apps for Consumer Auth
  • Example apps for B2B SaaS Auth
  • iOS example app
  • Android example app
  • React Native example app

If you're integrating the SDK directly into your application, you will need to check and ensure your SDK version is compatible with DFP Protected Auth. Here are the minimum versions for each SDK:

  • Vanilla JS SDK: v2.2.0
  • React Native SDK: v0.12.0
  • iOS SDK: v0.18.0
  • Android SDK: v0.14.0

Step 2: Enable Observation mode

With your auth SDK installed, you will need to enable DFP Protected Auth under Frontend SDKs in the Dashboard. By default, Stytch enables Observation mode when you first turn on DFP Protected Auth.

Turning on DFP Protected Auth

Observation mode automatically generates and submits a fingerprint to the Stytch API. However, the Stytch API will not enforce any action based on the fingerprint verdict.

This mode allows you to test out DFP Protected Auth on real traffic without risk. In Observation mode, DFP Protected Auth won’t block any requests before you have a chance to analyze the results.

Step 3: View the results in the Dashboard

Once you have DFP Protected Auth enabled in Observation mode, you can start seeing the results of the automatic fingerprint lookups at the Device Fingerprinting Dashboard.

DFP Dashboard

The Device Fingerprinting Dashboard will give you a high-level view of the various fingerprints, verdicts, and verdict reasons your application is experiencing. You can also deep-dive into individual fingerprints to understand the various devices that are querying your service.

Step 4: Turn on Enforcement mode

Once you are comfortable with the Device Fingerprinting verdicts for your traffic, you can switch to Enforcement mode. Once Enforcement mode is on, the Stytch API will react to each Device Fingerprinting lookup triggered by the SDK. Specifically, it will:

  • For ALLOW verdicts, continue requests in the normal authentication flow.
  • For BLOCK verdicts, reject requests and return a 401. You can be confident that a BLOCK verdict is an illegitimate attempt to access your service.
  • For CHALLENGE verdicts, by default the Stytch API will continue requests as if they received an ALLOW. This behavior is configurable and you can learn about your options in the guide for handling challenge verdicts in Protected Auth.
DFP Enforcement mode

With Enforcement mode enabled, your application's auth flows are now secured with DFP Protected Auth.

What's next

Learn about handling challenges with DFP Protected Auth.

Before you start

Step 1: Install the frontend auth SDK

Step 2: Enable Observation mode

Step 3: View the results in the Dashboard

Step 4: Turn on Enforcement mode

What's next