/
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
      Migrating from Stytch Consumer to B2B
      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
      Remembered device flow
    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 Apps
      Overview
      Getting started with the SDK
      Getting started with the API
      Client types
      OAuth scopes
    • Integration Guides

      • Integrate with an Existing Auth System
        MCP Authorization Overview
        Integrate with MCP servers deployed on Cloudflare
        Integrate with MCP servers on Vercel
        Integrate with CLI Apps
        Integrate with AI agents
    • Resources

      • Consent Management
        Custom Domains
        Testing Integrations
    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
    Trusted Auth Tokens
      Overview
      Getting Started with External IDPs
      Getting Started with Custom Auth Factors
    Device History
      New device notifications

    RBAC

    Resources
      Overview
      Role assignment
    Integration Guides
      Start here
      Backend integration
      Headless frontend integration
      (Legacy) 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

/

Connected Apps

/

Resources

/

Testing Integrations

Testing a Connected App Integration

In this guide, you'll learn how to test that your Stytch-powered app is functioning properly as an Authorization Server. We will perform a complete OAuth 2.0 / OIDC Authorization Code flow using the OAuth Debugger. The OAuth Debugger will function as a Connected App - it will build an authorization request to your application and assist in obtaining access tokens.


Prerequisites

Before testing, follow one of the Getting Started or Integration guides to create your initial integration. You should have implemented an Authorization URL within your application that handles the OAuth Consent flow.

Note: The Authorization URL page requires the user to already be logged in to your app; redirect unauthenticated users to your login flow before rendering the consent screen.


1
Configure a Connected App client

Create a new Connected App client for use with the OAuth Debugger.

  1. Navigate to the Connected Apps page in the Dashboard and click Add Application.
  2. Follow the wizard to create a new Third Party application using Public authentication.
    • You can also create a First Party application, which may skip the consent screen. See the Consent Guide for details.
  3. Name the client "OAuth Debugger" and add https://oauthdebugger.com/debug as a Login Redirect URL.
  4. Save your changes. You can leave the other fields as-is for now.
  5. Copy the client_id for use in the next step.

While you are here, it is good to verify that the Authorization URL is configured correctly:

  1. Navigate to the Settings tab.
  2. Ensure there is a valid URL in the Authorization URL input.

2
Build the authorization request

Open the OAuth Debugger and fill in:

  • Authorize URI: Your app's Authorization URL (this is your page within your application).
    Example: https://example.com/oauth/authorize.
  • Redirect URI: https://oauthdebugger.com/debug.
  • Client ID: the Connected App's client_id from step 1.
  • Scope: Start with profile email for now.
  • State: Leave the default value for now.
  • Nonce: Leave the default value for now.
  • Response Type: Leave as code.
  • Use PKCE?: Yes.
    • Make sure SHA-256 is selected.
    • Use the default Code Verifier and Code Challenge.
  • Token URI: Your project's unique Token Endpoint.
    • Should be of the form https://${projectDomain}/v1/oauth2/token.
    • You can find your Project Domain on the Project Overview page in the Dashboard.
  • Response mode: Leave as query.

Click Send Request. You'll be redirected to your Authorization URL, the user will be prompted for consent when applicable, and then redirect back to OAuth Debugger with a code.

3
Exchange the authorization code for tokens

The OAuth Debugger should automatically exchange the code that was returned for a set of tokens. You should see an access_token JWT in the response. Copy the access token and paste it into a JWT decoder such as jwts.dev.

You should be able to validate the following:

  • Scopes: The scope claim in the access token should be what you initially requested.
  • Issuer: The iss claim should be your unique Stytch project domain.
  • Audience: The aud claim should be your unique Stytch project ID.
  • Subject: The sub claim should be the ID of the Stytch user that granted access.

4
Other things to try

You can vary the parameters in the OAuth debugger to simulate different scenarios:

  • ID Tokens: When the openid scope is requested, an id_token will be returned in the response.
  • Refresh Tokens: When the offline_access scope is requested, a refresh_token will be returned in the response.
  • Custom and other built-in scopes: If your project defines any Custom Scopes, you may test them here as well.

Troubleshooting

  • Redirect mismatch
    Ensure the exact oauthdebugger redirect (https://oauthdebugger.com/debug) is registered on the Connected App. Mismatches will fail validation.

  • Consent not shown
    First-party clients may skip explicit consent depending on configuration; third-party clients always show consent. Refer to the Consent Guide for details on when consent is required.

  • PKCE errors
    If the token exchange fails due to PKCE, confirm that the code_verifier corresponds to the original code_challenge (S256).

Prerequisites

1.

Configure a Connected App client

2.

Build the authorization request

3.

Exchange the authorization code for tokens

4.

Other things to try

Troubleshooting