/
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
      Migrating from Stytch Consumer to B2B
      Exporting from Stytch
    Custom Domains
      Overview

    Authentication

    Single Sign On
    • Resources

      • Overview
        External SSO Connections
        Standalone SSO
    • Integration Guides

      • Start here
        Provider setup
        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 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 a remote MCP server
        Integrate with AI agents
    • Resources

      • Consent Management
        Custom Domains
        Testing Integrations
    Sessions
    • Resources

      • Overview
        JWTs vs Session Tokens
        How to use Stytch JWTs
        Custom Claims
        Custom Claim Templates
    • 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
    • Resources

      • Overview
        Strength policy
    • Integration Guides

      • Pre-built UI frontend integration
    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
    Trusted Auth Tokens
      Overview
      Getting Started with External IDPs
      Getting Started with Custom Auth Factors
    Device History
      New device notifications

    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

/

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 member 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