Resources

A Resource is an OAuth Resource Server: the API or MCP server a client requests access to.

When a client authenticates, it specifies which Resource it needs and what scopes it's asking for. Descope evaluates those requests against the scope catalog on that Resource and the Policies you've defined, and issues an access token carrying only the permissions granted. Your server then validates the token's aud, scope, and other claims before serving any request.

Resource access is dictated by Policies. They govern which subjects can receive which scopes on which Resources, across your Descope Applications (Inbound Apps and Agentic Clients).

Manage Resources in the Resources section of the Descope Console. There are two types:

When You Need a Resource

Any OAuth client that requires specific scoping, and needs a front between itself and the thing it is actually accessing, requires a Resource. Two cases come up constantly:

• Agents reaching external services. An agent that needs Google or HubSpot should not hold those providers' tokens directly. Instead, define a Resource whose scopes map to the underlying provider scopes. The agent authenticates to the Resource with a Descope token, and the Resource exchanges it for the Connection token when a tool runs. For agentic use cases this Resource is most commonly an MCP server, but it can be a plain API.
• Internal services without proper OAuth. If an internal API has no scoping of its own, define it as a Resource: it gets an audience, a scope catalog, and Descope-validated tokens without you building any OAuth infrastructure.
• M2M services whose permissions you want to control. A machine-to-machine client authenticating with client_credentials has no user consent in the loop, so the Resource's scopes are the only permission boundary it has. Define scopes on the Resource the M2M client accesses, then use policies to decide which of those scopes each client receives; the client only ever holds the resource access you granted it.

Scopes Live on the Resource

Only your API or MCP server knows the full set of actions it can perform. That's why scopes are defined on the Resource rather than on each client that calls it. Clients request the scopes they need; the Resource defines which scopes exist and what rules govern them.

Keeping the permission catalog in one place also means clients don't drift out of sync as your API evolves. Add a new scope to the Resource and any associated client can request it immediately, with no client-side config changes required.

Three things follow from that model:

1. Register the service: Add an API or MCP Server Resource with its audience (aud) and scope list.
2. Grant client access: Register the Inbound Apps or Agentic Clients that will access this Resource.
3. Set access rules: Apply Policies to control which subjects can receive which scopes at token issuance, across all applications and agentic clients. For API Resources, you can also map scopes to RBAC roles so users can only approve permissions that their roles allow.

Multiple clients can access the same Resource, and a single client can access multiple Resources:

Clients

M2M client

Inbound App · client_credentials

Autonomous agent

Agentic Client

Internal web app

Inbound App · authorization code

Resources

Shipments API

API Resource

Calendar MCP

MCP Server Resource

Reports API

API Resource

Each line is a token relationship: the client authenticates and receives an access token scoped to that Resource's audience and scopes. One client can access many Resources; one Resource can be shared by many clients — each with its own allowed scope set.

RelatedInbound AppsAgentic ClientsManaging Resources

Two ways to model Resources

However your agents reach your services, each target needs a Resource so the token has a valid audience and the agent has a standardized way to tell Descope what it is trying to access:

• One Resource per service. Define a Resource for each API or MCP server an agent connects to. Each has its own audience and scope catalog.
• One Resource for a gateway. If you run a gateway that fronts many downstream MCP servers and APIs, define a single Resource for the gateway's audience. The gateway routes each call to the right downstream target behind it.

In both cases Descope is the authorization server: it issues the token for the Resource's audience, and your service validates it before serving the request.

Keep credentials off the agent

Resources are also how you avoid handing long-lived secrets to an agent. An agent can fetch a Connection token directly with a user JWT (see Connecting an Agent Directly for a support-agent example with the Agent Auth SDK), but the recommended pattern puts a Resource, an MCP server or gateway, between the agent and the Connections vault:

1. The agent authenticates to the Resource and receives a short-lived, scoped token for it.
2. The Resource pulls the API key or external OAuth token from Connections at runtime.
3. The Resource calls the downstream service and returns only the result.

The agent never sees the third-party API key or OAuth token, which are often not short-lived. This is what the MCP scope to Connection scope mapping on a Resource is for.

Using a Resource Token

Descope issues the access token when the client authenticates at the authorization server: through the authorize flow (login and consent where required) and a call to the token endpoint, naming the target Resource via resource when needed. The client then calls the Resource directly with that token; aud matches the Resource identifier and scope carries the permissions Descope granted.

If the client needs to reach a different Resource, one with a different audience or scope set, it exchanges the existing token at the Descope token endpoint (RFC 8693) for a new token scoped to that target. The original token doesn't need to be re-issued; the exchange produces a new one for the specific resource being called:

1Authenticate for the first Resource

OAuth client or agent

Inbound App or Agentic Client

authenticate

Descope AS / STS

Token endpoint

Descope JWTaud + scopes → Resource A

Resource A

API or MCP Server

2Exchange for a different Resource

OAuth client or agent

Inbound App or Agentic Client

token exchange

Descope AS / STS

Token endpoint

Descope JWTaud + scopes → Resource B

Resource B

API or MCP Server

The client keeps its original token. To reach a different Resource — one with a different audience or scope set — it posts a token exchange request with the existing token as subject_token, plus the target resource URI and requested scopes. Descope issues a new JWT scoped only to that Resource.

RelatedToken endpointAuth patternsToken claims

Pricing

Access to a Resource is metered by how the token is obtained, not by how many requests the client makes afterward:

• User-delegated access, where a user consents to scopes (typically the authorization code flow), counts as a Monthly Active Consent (MAC): one per unique user, per Resource, per month, no matter how many times that user reconnects.
• Autonomous access, where a client authenticates as itself with no user (client_credentials and other machine-to-machine grants), counts as an M2M exchange.

If serving a request pulls a vaulted credential from a Connection, that adds a Monthly Active Token (MATK): one per user or tenant, per Connection, per month.

See the Descope pricing page for current rates and the complete definitions.

API Resources

An API Resource represents a service you operate as an OAuth resource server: platform APIs, partner integrations, or backends exposed to Inbound Apps and agents.

What You Configure

• Resource identifier: Used as the token aud and in discovery metadata so clients target the correct server.
• OAuth scopes: Permission strings your API enforces (for example shipments.read, admin:reports).
• Role association: Map each scope to one or more Descope RBAC roles. Only users who hold an associated role can consent to or receive that scope.

See Scopes and roles: API Resources for the full model.

OAuth Clients for APIs

After you create an API Resource, create Inbound Apps or Agentic Clients to let applications and agents request tokens against it. Inbound Apps and Agentic Clients own grant types, consent flows, and session management. The scope catalog and role mapping live on the Resource.

MCP Server Resources

An MCP Server Resource represents an MCP server you're building. It registers your MCP server URL as the token audience (aud), publishes OAuth discovery metadata, and defines the tool-level scopes clients request at authorization time.

What you configure

• MCP Server URL. Base URL of your MCP endpoint (typically ending in /mcp). Included in the aud claim on issued tokens.
• MCP Server Scopes. Permissions your server enforces per tool (for example mcp:calendar.read).
• Connection Scope Mapping. Map each MCP scope to Connection scopes so Descope knows which vaulted credentials to issue at tool runtime.

MCP Server Resources don't use the API Resource role-mapping model. Access control for agents goes through Policies and optional connection scope mappings.

See Scopes: MCP Server Resources and MCP server settings for operational details.

Token Validation

Once you've defined a Resource, your backend or MCP server should:

1. Validate JWT signatures using your project's public keys (session validation).
2. Verify that iss, exp, and aud match this Resource.
3. Enforce required scope: and for API Resources, optionally roles from RBAC.

All Resource tokens in a project share the same signing keys (JWKs).

Next Steps

• Managing Resources: create, associate with Inbound Apps and Clients, and delete
• Scopes and roles: API scope ↔ RBAC mapping; MCP scope ↔ Connection mapping
• Policies: control which subjects receive which scopes, across all applications and agentic clients
• Inbound Apps: OAuth clients for API Resources
• MCP Servers: operating MCP Server Resources in the Agentic Identity Hub
• Developing APIs with OAuth: enforce scopes on API Resources