Stytch Connected Apps

Connected Apps is a Stytch product that enables your application to become an OAuth and OIDC Authorization server. Being an Authorization Server means that your Stytch-powered app can safely and securely share user data with other applications or services. This enables users of your Stytch app to use their in-house tools, external integrations, desktop apps, AI agents, or any other compatible tools to access data stored in your Stytch application.

OAuth (open authorization) is a framework of protocols that allow an end user to grant websites or applications access to the user's account data, without sharing critical account credentials like passwords. OAuth defines procedures for clients to obtain access tokens from an authorization server with the consent of the end user. OAuth also defines protocols for clients to present these access tokens to resource servers to access protected resources.

OIDC (OpenID Connect) is an additional identity layer built on top of the OAuth framework. OIDC defines mechanisms that enable applications to verify the identity of the end user and view profile information such as their email address. Because OIDC further standardizes OAuth, it is a preferred integration approach for many off-the-shelf tools. Many OAuth authorization servers are also OIDC authorization servers.

There are four key entities involved in an OAuth transaction: the client, the resource owner, the authorization server, and the resource server.

• Client: The client is the entity seeking authorization to obtain access to the resource owner's account or resources. The client is often also referred to as the application or relying party.
• Resource owner: The resource owner, or the end user, is entity that owns the resources the client is trying to access. The resource owner grants authorization to the client.
• Authorization server: The authorization server is the service that verifies the identity of the user and the client, and mints access tokens for the client to use at the resource server. The authorization server is often referred to as the Identity Provider (IDP).
• Resource server: The resource server is the service that hosts the resource owner's resources. The resource server validates the access token minted by the authorization server.

There are multiple flows that the client, resource owner, and authorization server can participate in that result in an access token. These flows are referred to as "grant types". Different grant types can be used depending on the circumstances of the interaction.

• The Authorization Code Flow, also known as the Three-legged OAuth flow, is based on browser redirects with active user involvement. Authorization code flows grant a client access to a specific user's data on behalf of that user. This is the most common OAuth flow.
• The Refresh Token Flow is an optional additional procedure that clients can use for long-term background access to a user's account after the initial authorization code flow is complete.
• The Client Credentials Flow grants a client access to data based on the client's own identity, without any user involvement whatsoever. In Stytch, Client Credentials flows are built using a separate M2M product.

Unlike most CIAM providers, rather than requiring you to use a separate authorization server, Stytch provides a set of APIs, SDKs, and UI components that you can use to easily build your own authorization server. This approach means that the user experience feels like your users never leave your application rather than navigating to a separate site with its own design and user experience idioms. This provides reassurance to users who might otherwise feel uncertain about taking sensitive actions with a third party (like providing authentication credentials). Additionally, you can customize different parts of the flow to use your own domain, codebase, UI components, etc.

Specifically, your app is responsible for hosting the Authorization Endpoint. The Authorization Endpoint is a web page that the end-user's User Agent is redirected to by the client. For example, the client app might have a "Log in with Your App" button that redirects the user to your endpoint. The web page validates that the user is logged in, and if necessary, prompts them for consent to share their data. After the user responds, the web page redirects the user back to the client with an authorization code. The client can then exchange the authorization code for an access token for future use.

The Authorization Endpoint UI experience can be built using Stytch's Frontend SDKs directly embedded in your app or with Stytch's API endpoints for complete control over the interaction.

Read on for next steps:

• Get started with the Frontend SDKs
• Learn about the different types of clients that can be used
• Define custom scopes and resources to control how data is shared with clients
• Log users in with other commonly used IdPs such as Google and Microsoft ActiveDirectory with OAuth
• Learn more about Machine-to-Machine authentication with M2M