Understanding Client Types in Stytch Connected Apps

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)?

Combining these yields four distinct client types: First-Party, First-Party Public, Third-Party, and Third-Party Public.

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

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

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.

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.

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. Localhost or loopback redirects are not allowed.
• Refresh tokens do not rotate; they remain valid until revoked or expired.

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.

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

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 endpoint to start a secret rotation flow.

You can also create and manage clients through the Connected Apps section of the Stytch Dashboard.

Dynamic Client Registration (DCR) enables clients to be created at runtime instead of being pre-registered.

This is most common in the MCP ecosystem.

These clients can register themselves using the Dynamic Client Registration endpoint.

This feature must be enabled in the Connected Apps section 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.

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

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

Note: CIMD is an IETF draft specification. Changes in validation logic may occur before final adoption.