Auth Patterns

This page covers how agents get tokens from the Agentic Identity Hub and where downstream credentials come from.

How It Works

Agents connect to Resources as OAuth clients. A Resource is an API or MCP server that Descope protects as its authorization server.

When an agent connects, Descope applies your policies and issues a Resource token for that one Resource, with only the scopes the agent was granted.

When the API or MCP server behind that Resource needs downstream access, the Resource uses the access token to fetch a Connection credential, used for any API that doesn't accept Descope tokens (third-party services or your own), or exchanges it for a token for another Descope-protected Resource.

Policies apply again at each of those requests. With a Resource in front, the agent only ever holds its own Resource token.

Select any part of the diagram to see what it does.

Clients and Agentic Identities

In Descope, an agent is a client. The client is the agent's registration: it holds the Client ID, credentials, an owner, and tags, and it's the same kind of object as an Inbound App.

An agentic identity records whose behalf the agent is acting on. It takes one of two forms:

• Delegated agent: The agentic identity is the combination of the client and the user the agent acts on behalf of. Descope creates one the first time each user authorizes the client, so one client can have many agentic identities, one per user
• Autonomous agent: The agentic identity is one-to-one with the client, because the agent acts on its own behalf. Descope creates it as soon as the client has the client credentials grant enabled

The split mirrors standard OAuth, where a registered client is one entity and a user's grant to that client is another. Each agentic identity gets a stable ID, so audit logs can tie an action to the exact client and user pair behind it.

Credential Issuance Patterns

An agent gets its first token with one of the authentication grants enabled on its client, then gets downstream credentials for anything further down. Every token is short-lived, scoped, and can be validated on every request, so each action traces back to the agent's agentic identity.

The patterns work the same way whether the agent calls through a gateway, your REST APIs directly, or through an MCP server.

User Delegation

The agent acts on behalf of a signed-in user. The user authenticates through the User Consent Flow, which can include SSO, MFA, and a consent screen, and Descope returns an access token, a refresh token, and an ID token when the openid scope is requested.

The User Consent Flow is a Descope Flow, so you choose how users sign in by editing it, the same way you would edit any other login Flow. Inside the Flow, you can use Descope's authentication methods, hand off to your login system with the External Authentication action, or send users to a customer's IdP over SSO. See Bring Your Own Auth, for how to connect an existing login system.

Three grants support this:

• Authorization code with PKCE: the standard browser redirect. Confidential clients also authenticate at the code exchange, while public clients such as CLIs, native apps, and MCP clients rely on PKCE alone.
• CIBA: for agents with no browser. The agent starts the request and the user approves it on another device.
• JWT bearer with a user assertion: the agent presents a signed assertion that represents the user, such as an ID-JAG from a customer's enterprise IdP, instead of sending the user through a browser.

Refreshing a token returns the same scopes that were granted when the refresh token was issued.

Autonomous Access

The agent acts as itself, with no user involved: background workers, scheduled jobs, and agent-to-agent calls in multi-agent pipelines.

Two grants currently support this type of access:

• Client credentials: the agent sends its client ID and secret. Enabling this grant on a client creates its agentic identity automatically.
• JWT bearer with a workload identity: the agent presents a signed JWT from an issuer you trust instead of a Descope secret. Agents running in AWS or GCP use this to present their workload identity token, so there's no secret to store or rotate.

Where Policies Apply at Sign-In

Policies apply at different points depending on the grant. For client credentials, policies limit which scopes the client can get at the token endpoint, regardless of what it asks for. For user-delegated grants, policies limit which scopes appear on the consent screen.

Downstream Credentials

Once an agent or Resource holds a Descope token, it gets credentials for anything further downstream in one of two ways:

• Another Resource: A token exchange at the token endpoint returns a Descope JWT scoped to that Resource.
• A Connection: A fetch from the Connection token endpoints returns the stored OAuth token or API key.

Each hop gets its own credential while keeping the original user's identity, and a policy is checked at each one. There's no consent screen. For the requests, the setup, and when forwarding the inbound token as-is is acceptable, see Downstream Credential Access.

Who Gets Downstream Credentials

Either the agent or the Resource it calls can get downstream credentials:

• In your agent: Agent code that you write and run, such as a LangGraph agent or a background job, calls Descope directly for each downstream credential.
• In the Resource: The agent calls your API, MCP server, or gateway with only its own token, and that server gets the downstream credentials.

Off-the-shelf MCP clients such as Claude Code, Claude Desktop, and Cursor don't get downstream credentials themselves. For those agents, the Resource always does it. Both options use the same Descope endpoints, tokens, and policies, so you can use both at once without changing your identity configuration.

Keeping this in the Resource is the safer default, because long-lived third-party credentials never reach the agent.