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

# Client types in Stytch Connected Apps

> Understand the different types of OAuth clients

Stytch's Connected Apps feature enables Stytch-powered Applications to act as the Identity Provider (IdP) for OAuth 2.0 clients—these might be internal tools, third-party integrations, or community-built apps. All clients fall into one of four categories, defined by two key properties:

1. **Ownership**: Is the app *first-party* (owned by you) or *third-party* (built by an external developer)?
2. **Confidentiality**: Is the app *confidential* (able to securely store a client secret) or *public* (unable to store secrets securely)?

### Client types

Combining ownership and confidentiality yields four distinct client types:

* **First-Party**
* **First-Party Public**
* **Third-Party**
* **Third-Party Public**

<Info>
  Connected Apps always act on behalf of an end user and are constrained to a subset of that user's permissions. For non-interactive machine identities that act independently of user sessions, refer to the M2M Product.
</Info>

Additionally, clients can be created in a variety of different ways depending on your use case:

* via the Stytch Platform Dashboard and APIs
* via Dynamic Client Registration
* via Client ID Metadata documents

***

## **Use Case Overview**

| Use Case                                                               | Recommended Client Type |
| :--------------------------------------------------------------------- | :---------------------- |
| Secondary sites you own and want to share user data with               | First-Party             |
| Native mobile apps or CLI tools developed by you                       | First-Party Public      |
| Third-party integrations that want to access user data (e.g. plugins)  | Third-Party             |
| Third-party CLI tools, desktop apps, or dynamically registered clients | Third-Party Public      |

***

## **Ownership**

### **First-Party Applications**

These are trusted applications developed and managed by you, the owner of the Stytch project. First party applications are:

* Often **exempt from explicit consent** screens, depending on your configuration and scopes.
* Eligible for **session exchange**, enabling session sharing across websites and devices.

### **Third-Party Applications**

These apps are built and maintained by external developers or companies.

* **End-user consent is required** for all interactions.
* **Session exchange is not supported**—access is scoped strictly to the OAuth tokens issued.

***

## **Confidentiality**

### **Confidential Clients**

Confidential clients are capable of storing secrets securely, typically traditional server-based applications. Confidential clients are:

* Issued a **client secret** which can be used via `client_secret_post` or `client_secret_basic` authentication mechanisms. **PKCE** is recommended but not required.
* Must adhere to strict **HTTPS redirect URIs** in production. `http://Localhost` or loopback redirects are not allowed.
* **Refresh tokens do not rotate**; they remain valid until revoked or expired.

### **Public Clients**

Public clients run in environments where secure storage is not possible, such as native or CLI apps. Public clients:

* Are not issued a client secret and use the `none` authentication strategy. Public clients **must use PKCE** for secure authorization code exchange.
* May use more **permissive redirect URIs**, including loopback and custom schemes.
* **Refresh tokens rotate** on use, and the platform **detects replay attempts** to guard against theft.

***

## **Client Creation Methods**

### **Stytch Platform API**

Clients can be created programmatically using the Create Connected App endpoint. This is the most common method for creating clients.

When creating a client, you specify the `<client_type>` parameter to determine the type of client:

* `first_party` : Creates a First-Party Confidential Client
* `first_party_public` : Creates a First-Party Public Client
* `third_party`: Creates a Third-Party Confidential Client
* `third_party_public` : Creates a Third-Party Public Client

<Info>
  **Important:** When creating confidential clients `first_party` or `third_party`), the API returns a `client_secret` in the response. This is the only time you will be able to view the secret.

  Stytch stores only a hash and cannot recover it if lost. Store it securely immediately. If you need a new client secret, use the **Start Secret Rotation** (for [B2B](/api-reference/b2b/api/connected-apps/rotate-secret/start-secret-rotation), for [Consumer](/api-reference/consumer/api/connected-apps/rotate-secret/start-secret-rotation)) endpoint to start a secret rotation flow.
</Info>

You can also create and manage clients through the [Connected Apps section](https://stytch.com/dashboard/connected-apps) of the Stytch Dashboard.

### **Dynamic Client Registration**

Dynamic Client Registration (DCR) enables clients to be created at runtime instead of being pre-registered. This is most common in the [MCP](/connected-apps/guides/mcp-auth-overview) ecosystem. These clients can register themselves using the Dynamic Client Registration endpoint (for [B2B](/api-reference/b2b/api/connected-apps/application-management/dynamic-client-registration), for [Consumer](/api-reference/consumer/api/connected-apps/application-management/dynamic-client-registration)).

**How it works:**

This feature must be enabled in the [Connected Apps section](https://stytch.com/dashboard/connected-apps) of the Dashboard. Once enabled, clients can self-register by submitting a JSON payload containing:

* Client name
* Redirect URIs
* Desired authentication method `none`, `client_secret_post`, or `client_secret_basic`)

**Considerations:**

* All dynamically registered clients are **Third-Party Public** or **Third-Party Confidential** clients, depending on the authentication method specified.
* Stytch automatically deduplicates public clients based on a hash of the metadata—if an identical client already exists, the same `client_id` is returned instead of creating a duplicate.
* Confidential clients (which are granted a `client_secret`) will always be issued a unique client ID.

<Info>
  CIMD is an emerging standard that offers a more secure alternative to Dynamic Client Registration, which has numerous operational issues in large enterprise environments. You can read more about the limitations of DCR [here](https://blog.modelcontextprotocol.io/posts/client_registration/).
</Info>

### Client ID Metadata Documents (Beta)

Client ID Metadata Documents (CIMD) enable OAuth clients to self-describe by hosting their own registration metadata at an HTTPS URL and using that URL as their `client_id`. Instead of manually registering with Stytch ahead of time, Stytch will fetch and validate the client metadata during authorization.

**How it works:**

1. A client hosts a JSON metadata document at an HTTPS URL (e.g., [https://client.dev/oauth/metadata.json](https://client.dev/oauth/metadata.json))
2. The client uses this URL as its `client_id` when initiating OAuth flows
3. Stytch fetches the document from the URL and uses its contents as the client's configuration

This feature must be enabled in the [Connected Apps section](https://stytch.com/dashboard/connected-apps) of the Dashboard.

**Considerations:**

* Stytch will refresh the client's metadata periodically, which means that manual changes to the client via the Dashboard or the API may be overwritten at a later date.
* All clients created via CIMD are Third-Party Public clients.
* The `client_id` and `client_uri` fields must have the same origin.

<Info>
  **Note:** [CIMD](https://client.dev/) is an IETF draft specification. Changes in validation logic may occur before final adoption.
</Info>