Connected Apps Authorization Code Flow

OIDC is an industry standard for allowing applications to ask an Authorization Server—your Stytch-powered application—to verify the identity of a user. By logging in a user in this way we can consolidate information about a user’s authentication and authorization in Stytch and manage user data in one centralized location across multiple apps. To ground our discussion about Connected Apps we will discuss the OIDC Authorization Code Flow (in the Connected App configuration, this is a “confidential app”, described below). At the end of the article we will cover modification of this flow for “public apps” - Authorization Code Flow with PKCE.

Authorization Code Flow

The general flow for the Authorization Code Flow for a Connected App proceeds as follows:

A user using the Connected App wishes to authenticate this app with your Stytch-powered Authorization Server in order to access user information (what we’re implementing here). They click a button or follow a link to an Authorization URL (configured below) owned by your Stytch app.
The Stytch API is called. When using the Stytch frontend SDK, to begin the login flow, the Connected App will redirect the user’s browser to an Authorization URL in your Stytch-powered application. This page will host a mounted Stytch component that will catch the URL parameters provided to the Authorization URL page and proceed with the login flow. After the initial step succeeds, Stytch will respond with a redirect to send the user’s browser to the Connected App’s redirect_uriwith a code for the Connected App to complete the flow on its backend. The redirect to this page should include these URL parameters as defined in the OIDC specification:

Name	Meaning
`response_type`	The response type of the OIDC request. For Authorization Code Flow this is always `code`
`scope`	The scope of access of the user information. Typically one or more of `openid`, `profile`, `email`, `phone`
`client_id`	The Stytch client app id, which you will receive when configuring a Client App (below)
`redirect_uri`	The URI owned by the Connected App to call back when Stytch verifies access is granted. After the initial steps of the login process, Stytch redirects to this URI. You will configure this in Stytch when configuring a Connected App (below)
`state` (optional)	An opaque value (not used by the flow) which will be passed back and forth throughout the flow. This can be used in some enhanced security scenarios or to store information about user state that should be preserved throughout the flow.
`code_challenge`	Required for public clients, see here
`code_challenge_method`	Required for public clients, see here

The user may be prompted to verify that the Connected App has permission to access their data (depending on whether the Connected App is “First Party” or “Third Party). For more information, see our documentation about Client Types.
Upon success, the Stytch API returns both a redirect_uri, owned by the Connected App, and a code parameter. When using the frontend SDK, Stytch redirects the browser to the configured redirect_uri owned by the Connected App with a code parameter.
The Connected App uses this code parameter, along with its client_id and client_secret, to request an access_token (and optionally an id_token or refresh_token) from Stytch.

Once these steps are complete, the Connected App is logged in and can use the access_token to access user data.

What’s next

Learn more about Client Types
Learn more about OAuth Scopes
Configure a Connected App with the SDK or API.
- Follow this guide if you are configuring a public app

​Authorization Code Flow

​What’s next

Authorization Code Flow

What’s next