> ## Documentation Index
> Fetch the complete documentation index at: https://stytch.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Testing integrations

> Ensure your Stytch-powered app is functioning properly as an Authorization Server.

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](https://oauthdebugger.com/). 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.

<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
</Note>

## Test your Integration

<Steps>
  <Step title="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**](https://stytch.com/dashboard/connected-apps) 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**](/connected-apps/resources/consent-management) 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.
  </Step>

  <Step title="Build the authorization request">
    Open the [OAuth Debugger](https://oauthdebugger.com/) 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](/api-reference/b2b/api/connected-apps/exchange-authorization-code), for [Consumer](/api-reference/consumer/api/connected-apps/exchange-authorization-code)).
      * Should be of the form `https://${projectDomain}/v1/oauth2/token`.
      * You can find your Project Domain on the Project Overview page in the [**Dashboard**](https://stytch.com/dashboard).
    * **Response mode**: Leave as `query`.

    Click **Send Request**. You'll be redirected to your Authorization URL, the user will be prompted for [**consent**](/connected-apps/resources/consent-management) when applicable, and then redirect back to OAuth Debugger with a `code`.
  </Step>

  <Step title="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](http://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.
  </Step>

  <Step title="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](/connected-apps/oauth-learn-more/oauth-scopes#custom-scopes), you may test them here as well.
  </Step>
</Steps>

## 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](/connected-apps/resources/consent-management) 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`).