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 and access rules you've defined on that Resource, 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.

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

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 — 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 filter which scopes clients actually receive at token issuance. For API Resources, map scopes to RBAC roles so users can only approve permissions 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

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

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 scopes agents and users can receive
• 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