Stytch Connected Apps: Consent Management Guide

Stytch's Connected Apps infrastructure allows your application to serve as an Identity Provider (IdP), letting end users authenticate with first-party and third-party applications using OAuth. Consent management is a critical part of this flow, ensuring secure and auditable access control across users and applications.

This guide outlines how consent is requested, tracked, enforced, and revoked using Stytch.

Consent is the explicit authorization an end user gives to a Connected App to access specific data or perform actions on their behalf. This happens during the OAuth authorization flow and is recorded and enforced by Stytch.

Explicit consent is not always required for an application to receive access to an end user's data. The rules for when consent can be bypassed are different for First Party and Third Party clients.

In Stytch's Connected Apps model, first-party applications are those that are developed and managed by you, the developer. These apps are considered trusted by default, and the consent flow is typically streamlined to reduce unnecessary friction. Consent is often not required for first-party applications, depending on your configuration and scopes. However, the consent management endpoints can still be used to view how an end user's data is shared and to revoke access and refresh tokens issued to a particular client.

Third-party applications are external services not developed or maintained by you. Because these apps introduce new trust boundaries, Stytch enforces stricter consent and policy checks to ensure data is shared securely. These apps are considered untrusted by default and an end user must grant access via a consent screen before tokens can be issued. After consent has been granted, future OAuth flows will skip the consent screen unless the set of scopes being requested changes.

Certain OAuth flows will always require consent, regardless of the client type or whether consent has been previously granted. The scenarios where consent is always required are as follows:

1. The OAuth request passes the ?prompt=consent query parameter, which always forces a consent screen even if one wouldn't normally be shown.

2. The OAuth request asks for the offline_access scope in order to retrieve a refresh_token. Requiring consent to obtain a refresh_token is recommended by the OIDC spec. This case can be bypassed by enabling the Bypass user consent for offline_access scope flag on that client's page in the Dashboard. This flag is only available for first-party applications.

3. The redirect_uri uses a non-https:// scheme, such as myapp://oauth-callback. Explicit consent and user interaction is required for custom schemes to avoid impersonation of native apps. Developers are recommended to make use of schemes such as Apple's Universal Links or Android's App Links instead of custom schemes when possible.

4. The redirect_uri uses a loopback address like 127.0.0.1 or [::1], which are similarly at risk for impersonation.

End users are prompted to grant consent through the IdentityProvider UI Component.

This screen presents:

• The application name and branding
• The scopes (permissions) being requested
• A binary choice to approve or deny the request

Once explicitly granted, Consent is tracked and future login attempts will proceed automatically when possible.

Connected App consent grants can be managed programmatically. Use the Get Connected Apps endpoint to retrieve all Connected Apps a user has authorized. Unwanted authorizations can then be revoked programmatically via the Revoke Connected App endpoint. When a consent grant has been deleted, all access and refresh tokens issued to that connected app on behalf of the user will be revoked. A new OAuth flow must be completed in order to receive a new set of tokens.

Developers can also view and manage consent grants for a user from the dashboard UI.