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:
- Ownership: Is the app first-party (owned by you) or third-party (built by an external developer)?
- 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 .
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. 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 client_secret=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.