Clients

The Clients page is where you register, view, and manage the OAuth clients in your project. From here you can:

• Create clients manually for autonomous agents, pre-registered MCP clients, or any case where you want to configure credentials and grant types ahead of time
• View all clients registered in your project, including those created automatically via DCR or CIMD when MCP clients like Claude or Cursor connect to your MCP servers
• Manage clients — update tags, configure grant types, and delete clients that are no longer in use

Clients fall into two categories:

The Clients view in the Agentic Identity Hub provides an overview of all OAuth clients in your project. Clients are the OAuth applications that connect to your MCP servers, and they fall into two categories:

• Dynamically registered clients: Clients registered automatically through Dynamic Client Registration (DCR) or Client ID Metadata Documents (CIMD) when an MCP client like Claude, Cursor, or VS Code connects to one of your MCP servers.
• Manually registered clients: Clients you pre-register yourself, typically for autonomous agents using client_credentials or for cases where you have disabled DCR/CIMD on your MCP server.

Viewing Clients

Navigate to the Clients section in the Descope Console to see an overview of all your OAuth clients and their details.

Creating a Client

To create a new client manually, click the + Client button in the top right of the Clients page. The creation form is divided into several sections.

Client Details

The Client Details section captures the basic identifying information for the client.

Name

The client name is a required, human-readable identifier that helps you distinguish between clients in your project.

Description

The description is an optional field where you can provide additional context about the client, such as its purpose, owner, or environment.

Logo

You can optionally paste a logo for the client. When a client is registered dynamically through a well-known MCP client such as Claude, Cursor, or VS Code, Descope will pre-fill the logo for you automatically.

Tags

Tags are optional labels you can assign to a client for organization and categorization. You can add as many tags as you want. Press Enter after typing each tag name to add it to the client.

Tags help you group and filter clients based on custom criteria such as environment, team, or use case.

Grant Types

The Grant Types section controls which OAuth grant types the client is allowed to use. Enable a grant type with the toggle on the left; use Manage on the right to configure grant-specific settings.

Authorization Code

Used when an MCP client or application redirects a user through Descope for login and consent (for example Claude, Cursor, or VS Code connecting to your MCP server).

Click Manage to configure approved redirect URLs—the callback URIs Descope may return users to after authentication. Restrict this list to the URLs your client actually uses, so that authorization codes cannot be sent to unexpected destinations.

Client Credentials

Used when an autonomous agent or backend service authenticates with its client ID and secret and receives a token with no end-user session.

Enabling this grant type on a client automatically creates a corresponding agentic identity in the Agentic Identity view — no separate setup required.

Click Manage to set Allowed Tenants. By default a client can be used across your entire Descope project; add specific tenants to the list when you want to restrict the client to particular tenants only (for example a dedicated M2M agent per customer tenant).

JWT Bearer

Used when the client exchanges an external OIDC JWT for a Descope-issued token at the token endpoint. See External token management for examples of how to use this grant type.

Click Manage to register one or more trusted issuers for this client. Descope accepts JWTs from any issuer you add. For each issuer you configure:

You can add multiple issuers so a single client accepts JWTs from more than one external identity provider.

To learn more about how to use the JWT Bearer grant type, and how to use the Agentic Identity Hub with Workloads, see our doc on Using Descope with Workloads.

CIBA

Client-Initiated Backchannel Authentication, or CIBA, lets the client start authentication without redirecting the user's browser on the initiating device.

Instead, Descope notifies the user out of band to complete approval on another device. Click Manage to configure:

• Delivery method: Email is currently the supported channel. Choose a custom email connector and template for the approval message.
• Custom link expiration: How long the approval link remains valid (default 3 minutes).

Once you've enabled CIBA, you can configure the authentication experience users see when they open the link under Flows → CIBA.

Read more details on the CIBA model in Creating Inbound Apps —> CIBA.

Choosing Grant Types

Enable only the grant types the client will actually use. Unused grant types expand the attack surface without adding value.

• Authorization Code: Use this for any client that redirects users through a consent flow. If you are pre-registering a client instead of relying on CIMD or DCR, create the client here, copy the generated client ID, and configure it on the MCP client side.
• Client Credentials: Use this for autonomous agents and background services that authenticate as themselves with no user involved. Disable any other grant types on these clients.
• JWT Bearer: Use this when the client will authenticate by presenting an external OIDC token — for example, a workload running on AWS or GCP. See Workload Identity for setup details.
• CIBA: Use this when the client needs to initiate authentication without a browser redirect on the requesting device, routing approval to the user out of band.

Flows

The Flows section controls the experience users see when you run through OAuth grant types against this client.

User Consent

Under Flows, you can select the Descope Flow the client will run during the authorization code flow. This is where you configure the authentication and consent experience for end users.

You can also check the Skip consent screen box to bypass the consent screen entirely for this client. This is useful for trusted first-party clients where displaying a consent prompt would add friction without adding meaningful security.

CIBA Flow

If you enable CIBA, you can select the Descope Flow the client will run during the CIBA flow. You will be able to either select your own flow, or generate a pre-built flow that contains the required actions for the CIBA grant type.

Session Management

The Session Management section controls how tokens are issued and how long they remain valid for this client.

By default, this is set to According to system settings, which uses the project-level session settings. You can switch to Custom to override these defaults on a per-client basis.

Token Format

When using custom session management, you can choose between two token formats:

• User JWT: A JWT representing a user session. Relevant for authorization code and CIBA flows.
• Access Key JWT: A JWT representing a machine identity. Relevant for client_credentials flows.

Depending on which grant types you have enabled, one or both of these formats may apply to the client.

Token Expiration

You can configure the following expiration settings:

Managing Clients

Filtering Clients

You can filter the client list to find specific clients based on various criteria. Filter operators behave the same way as in the Agentic Identity view, supporting operators such as Contains, Equals, In, Matches, and timestamp comparisons across columns like Name, Client ID, and Tags.

Selecting Clients

Select one or more clients from the list to perform bulk operations such as managing tags or deleting clients.

Managing Tags

You can add or remove tags on individual clients or multiple clients at once.

Deleting Clients

Deleting a client removes the OAuth client and invalidates its client ID. Note that deleting a client is not the same as revoking access for an agentic identity.

Revoking access invalidates previously granted user consent while leaving the client ID intact, whereas deleting the client removes the OAuth client entirely.