Skip to main content
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.

​
Pre-requisites

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

​
Test your Integration

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 in the Dashboard, 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 (for B2B, for Consumer).
    • 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).