Skip to main content
Connected Apps is a Stytch product that enables your application to become an OAuth and OIDC Authorization server. Understanding some key OAuth concepts will help you as you get started implementing Connected Apps.

OAuth terminology

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

OAuth Grant Types

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.