Auth Patterns
This page covers the credential issuance patterns and integration architectures behind the Agentic Identity Hub.
Lifecycle Map
Every client authenticates at the Descope Authorization Server (AS) and receives a base access token scoped to your project.
With that token, it can then call a protected resource directly, or exchange the token at the Descope STS token endpoint for a credential scoped to a different audience, a narrower permission set, or a third-party API key / OAuth token stored in Connections.
When an agent needs credentials for a specific downstream service — a narrower scope, a different audience, or a stored API key — Descope exchanges the base access token on demand. Each hop in a chain gets its own credential without the agent re-authenticating.
Clients and Agentic Identities
An agent in Descope comprises of two objects. Understanding them individually makes the rest of this page easier to follow:
Client: the agent's registration. It holds credentials, an owner, tags, and a Client ID. It exists before the agent has done anything.
Agentic identity: a specific authorization record that binds a specific client to a specific principal — a user, a tenant, or (for autonomous agents) the client itself — on whose behalf the client is permitted to act. A single client can hold multiple agentic identities, one for each principal that has granted it access.
The distinction maps onto standard OAuth. A registered OAuth client is one entity. A user's grant to that client is another. Descope formalizes the same split for agents and gives each agentic identity a stable, addressable ID.
| Operation | Client | Agentic identity |
|---|---|---|
| Configure credentials and rotation | ✓ | |
| Set tags and ownership | ✓ | |
| Define attribute-based policies | ✓ | |
| Suspend the agent across all principals | ✓ | |
| Audit actions taken on behalf of a specific user | ✓ | |
| Revoke one user's or agents access without touching others | ✓ |
An agentic identity represents a software agent that acts autonomously or on behalf of a user or tenant.
Unlike a service account, it is designed for a system that makes runtime decisions:
- Authentication is non-interactive and machine-to-machine
- Authorization is capability-based and evaluated per request
- Credentials are short-lived by default
- Delegation is explicit and traceable
- Creation and decommissioning happen just in time
Agents are first-class identities in Descope. They operate independently or act under explicit delegation from a human user. Either way, there is a clear chain of accountability from every agent action back to an owner.
Credential Issuance Patterns
Note
Token refresh returns the same scopes that were granted when the refresh token was issued. Downscoping during refresh is not currently supported.
Descope supports three patterns, available across both direct agent integration and MCP server-based integration.
User Delegation
An agent acts on behalf of an authenticated user. The user authenticates through the User Consent Flow, which can include SSO, MFA, and consent screens customized in Descope Flows. Descope returns an access token, a refresh token, and an ID token when openid scope is requested.
Implemented as OAuth 2.1 authorization code flow with PKCE. Confidential clients authenticate with client credentials at the code exchange; public clients (CLIs, native apps, MCP clients) rely on PKCE alone.
Autonomous Access
The agent acts on its own behalf with no user involved. Used for service-to-service, machine-to-machine, and agent-to-agent calls: background workers, scheduled jobs, inter-agent calls in multi-agent pipelines.
Implemented as OAuth 2.1 client credentials flow. The agent authenticates with its client credentials and receives a token scoped to its permitted resources.
Note
Policies work differently depending on grant type:
For client_credentials flows, policies control which scopes the client is permitted to request at the token endpoint. The agent cannot obtain a scope that policy does not allow, regardless of what it asks for.
For authorization code flows, policies control which scopes a user can consent to in the consent screen. Scopes excluded by policy do not appear as options for the user.
Configure scope grants directly on the client record to constrain what an autonomous agent can request.
Token Exchange
Used for two scenarios that share the same mechanism:
Delegation chaining: when an agent calls another agent, an MCP server, or a downstream service that accesses further resources, each hop needs its own credential while preserving the original user's identity. The intermediate service presents a previously issued token alongside the target resource and receives a new token scoped to that resource.
Federation across identity systems: when an agent presents a token from another identity provider—a workforce IdP, a partner's AS, another Descope project, or a cloud workload identity provider like AWS or GCP—Descope validates the token against the configured trust relationship and issues an equivalent Descope token. No additional authentication redirects are required. See Using Descope with Workloads for AWS and GCP setup.
Both are implemented as OAuth 2.0 Token Exchange (RFC 8693). The exchanged token preserves the delegation chain, so policy evaluation and audit logs can trace the full path from the original user through every intermediary.
Integration Patterns
Choose a pattern based on how your agent calls resources. Both run on the same Descope endpoints, tokens, and policy engine — switching between them, or running both simultaneously, requires no changes to your identity configuration.
Direct Agent Integration
The agent authenticates directly to Descope and uses the resulting token against APIs, databases, or other resources. No MCP server in the path.
This pattern fits when:
- The agent calls REST APIs, internal services, or databases directly from agent code
- The agent runs as a background process, CI/CD job, or scheduled task that needs scoped credentials per run
- You're integrating with an agent framework (LangChain, LangGraph, or a custom agent) that manages its own tool dispatch
The client is pre-registered in the Descope console before deployment. The agent ships with its client_id and secret — no runtime registration required.
MCP Server-based Integration
The agent connects to one or more MCP servers, which handle token validation, scope enforcement, and credential brokering between the agent and downstream resources.
This pattern fits when:
- You expose tools to agents over the Model Context Protocol
- You want resource access logic kept out of agent code entirely
- You support MCP-aware clients like Claude, Cursor, or VS Code
When a tool calls a different downstream API — another Resource with a different audience, a third-party service in Connections, or a narrower scope set — exchange the inbound MCP token at the STS instead of forwarding it.
Passthrough (sending the MCP client's access token directly to a downstream service) is only viable when that service validates the same aud and scopes as the MCP server, and is generally not recommended for MCP tool handlers because:
- The MCP token's
audis your server URL — downstream APIs and third-party services expect their own audience or a vaulted credential, not an MCP-scoped JWT. - Policy runs once at MCP ingress; you cannot evaluate per-target rules (user, tenant, calling client, and your server's client) at the downstream hop.
- The audit trail does not record a distinct exchange event for each downstream service a tool accessed.
- The full MCP scope set is exposed to downstream services instead of a downscoped credential issued for that call.
The client discovers the authorization server metadata from your MCP server, then posts to /register. Descope returns a client_id and secret the client uses for all subsequent requests.