Allow apps to log in with your Stytch-powered app

In this guide, you'll learn how to configure your suite of OIDC applications to log in and perform actions on behalf of your users with your Stytch-powered app. This enables users of your Stytch app to use their in-house tools, external integrations, desktop apps, AI agents, any OIDC-compatible app to use your Stytch application as an Authorization Server, reducing user information duplication and simplifying the process of integrating Connected Apps with your app.

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.

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

1. 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.
2. URL parameters provided to the Authorization URL page are caught by a Stytch component which proceeds with the login flow with Stytch.
3. 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", described below)
4. Upon success, Stytch redirects the browser to the configured redirect_uri owned by the Connected App with a code parameter.
5. 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.

In order to complete this guide, you'll need:

• A Stytch project. If you don't have one already, in the Dashboard, click on your existing project name in the top left corner of the Dashboard, click Create a new project, and then select B2B Authentication or Consumer Authentication.
• A React or Next.js app authorized to use Stytch frontend SDKs
• A Relying Party app (the Connected App) that wishes to receive user information from your application.

const { member } = useStytchMember();

if (!member) {
  const loginURL = `/login?returnTo=${window.location.toString()}`
  return <Redirect to={loginURL} />
}

return <B2BIdentityProvider />

2

Configure Stytch for the component

We will configure your Stytch app in the Connected Apps section of the Stytch dashboard. Enter the URL where the component is mounted into the Authorization URL field.

3

Configure the Connected App(s) information

After Stytch handles verification of the user and the application’s ability to access the user’s information, Stytch will issue a redirect. This redirect is intended to go to a URL which should be supplied by the Connected App and provides some short-lived credentials that allow the Connected App to complete the authorization flow.

To set this up, each Connected App is also configured in the Connected Apps section of the Dashboard:

Upon creating a new Connected App we specify what type of user consent and OIDC flow the Connected App expects. Stytch supports connecting a few types of client apps which vary based on how much user consent is appropriate and specifics of the OIDC flow:

• First party apps are trusted within an organization and do not show a user consent screen before completing authorization.
• Third party apps ask each user if the app should be able to access their user information.
• Public apps use OIDC Authorization Code Flow with PKCE as they cannot securely store long-lived secret information.
• Confidential apps are assumed to have the capability to securely store secrets and use the OIDC Authorization Code Flow: what we've been discussing in this article so far.

Continue to configure the Connected App on the next screen. Make sure to take a note of the “Client ID” and the “Client secret” (for confidential apps); these will be needed by the Connecting App to complete the Authorization Code Flow.

The Connected App will also supply a Redirect URL for receiving the login information from Stytch after the initial login is complete. This should be entered into the “Redirect URLs” field.

At this point, off-the-shelf software should be prepared to authorize as a Connected App with Stytch.

curl --request POST \
  --url https://test.stytch.com/v1/public/$PROJECT_ID/oauth2/token \
  -d grant_type="authorization_code" \
  -d client_id="$CONNECTED_APP_CLIENT_ID" \
  -d client_secret="$CONNECTED_APP_CLIENT_SECRET" \
  -d code="$CODE_FROM_REDIRECT_PARAMETERS" \
  -d redirect_uri="$REDIRECT_URL"

A potential vulnerability exists in the OIDC flow due to the nature of it requiring two asynchronous requests to complete. A malicious party could intercept the code returned in the first step of authorization and attempt to use it to authorize their own app before the legitimate app exchanges it for an access_token. In the case of the Authorization Code Flow this is prevented by the fact that the pre-shared Client Secret is not known to the malicious actor so they don't have enough information to do the complete code exchange.

Due to the nature of, for instance, in-browser single-page apps with no backend, or mobile apps where secrets can be extracted from the app if distributed within the app, there is sometimes no location to safely store the client_secret. We call these "Public" apps. For these apps, we implement a variant of the Authorization Code Flow using PKCE (Proof Key for Code Exchange). This flow uses an extension to the Authorization Code Flow to ensure both requests used during the Authorization Code Flow come from the same Connected App.

When beginning the authorization request, the Connected App will construct a code_verifier (for example, generating a cryptographically random value) and use it to generate a code_challenge. The code_challenge is the SHA-256 hash of the code_verifier. On the initial request to Stytch—the request made to the page hosting the <IdentityProvider \> component—the additional URL parameters of code_challenge and code_challenge_method should be sent:

Upon receipt of this request, Stytch will save the value of code_challenge for later. After the user has granted permission for access, Stytch will return a code from this step just as in the regular Authorization Code Flow.

During the code exchange part of the process, the Public app will exchange the code for an access_token as the server would do in the Authorization Code Flow. However, the Public app has no access to a client_secret so cannot send that parameter. Instead, the Public app also sends the original code_verifier with this request:

Stytch will verify that its saved code_challenge was generated from this code_verifier before generating and returning credentials for the app. In this way it can be sure that the app that requested the code in the first request is the same app that is requesting the access_token in the second request.

Read more about our other offerings:

• 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