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

# Implementing your own Connected App

> Examples and considerations when implementing your own Connected App.

Generally off-the-shelf software will only need to be configured with the location of the Authorization URL, a Client ID, and a Client Secret for proper setup. Afterwards, the software should be prepared to authorize with Stytch.

If, however, you are implementing your own Connected App, or just curious, it's worth understanding the second part of the Authorization Code Flow—what happens upon the Connected App receiving the redirect.

### Server Side Flow

The server side flow is very similar to Stytch's M2M Authentication (for [B2B](/multi-tenant-auth/authentication/m2m/authenticate-client), for [Consumer](/consumer-auth/authentication/m2m/authenticate-client)) in that we will be exchanging the Connected App's own credentials for an access token. The difference in this case is that we will also exchange the `code` returned from integrating with the [SDK](/connected-apps/build-login-flow/login-flow) or [API](/connected-apps/build-custom-flow/getting-started-api). This `code` represents the ability of the client app to act *on behalf of the user.* Conceptually the code can be thought of as representing permission from the user to enable the app to see their data and act on their behalf.

To perform the token exchange, just as in M2M Authentication, we will make a `POST` request to your project's Token Endpoint. The endpoint is located at `https://${projectDomain}/v1/oauth2/token` (or similar, depending on your Stytch test or production environment or CNAME settings). See [this guide](/connected-apps/resources/custom-domains) to learn more about setting up a custom domain.

The request should contain these parameters:

| Name            | Meaning                                                                                                                                           |
| :-------------- | :------------------------------------------------------------------------------------------------------------------------------------------------ |
| `grant_type`    | The type of auth grant we're seeking. For Authorization Code Flow this is always `authorization_code`                                             |
| `code`          | The `code` received in a parameter of the request sent to the Redirect URL.                                                                       |
| `client_id`     | The Stytch client app id, which you will receive when configuring a Client App (below)                                                            |
| `client_secret` | The Stytch Connected App's Client Secret - required for confidential clients                                                                      |
| `redirect_uri`  | While there is no redirect issued from this request `redirect_uri` must be present and identical to the value used in the first part of the flow. |
| `code_verifier` | Required for public clients, see [this guide](/connected-apps/build-custom-flow/public-apps)                                                      |

For example, here is what such a request might look like using `curl`:

```bash theme={null}
curl --request POST \
  --url https://${projectDomain}/v1/oauth2/token \
  -d grant_type="authorization_code" \
  -d client_id="$CONNECTED_APP_CLIENT_ID" \
  -d client_secret="$CONNECTED_APP_CLIENT_SECRET" \
  -d code="$CODE_FROM_REDIRECT_PARAMETERS" \
  -d redirect_uri="$REDIRECT_URL"
```

The response from this request will be a JSON payload with the access token for authorizing requests from the Client App.