Wiki · Concept · Last reviewed July 1, 2026

OAuth Resource Indicators

OAuth Resource Indicators give a client a standard way to say which protected resource a requested access token is meant for, so the authorization server can shape the token and the resource server can reject tokens aimed elsewhere.

Category: Concept Published: June 25, 2026 Modified: July 1, 2026 Last reviewed: July 1, 2026 Tags: AI agents, authorization, OAuth, resource indicators, token audience, audit trails

Definition

OAuth Resource Indicators are the Standards Track extension defined in RFC 8707, Resource Indicators for OAuth 2.0, by Brian Campbell, John Bradley, and Hannes Tschofenig. RFC 8707 was published in February 2020. It adds a resource request parameter that lets an OAuth client explicitly signal the protected resource, also called the resource server, where it intends to use an access token.

The basic distinction is simple. A scope says what kind of access is requested, such as reading files or posting calendar entries. A resource indicator says where the resulting token is intended to be used. In multi-resource systems, that difference is not cosmetic. The same scope string can mean different things at different APIs, and a token that is valid everywhere is harder to contain after leakage, counterfeit-resource phishing, or confused delegation.

For AI agents, resource indicators matter because agents often discover tools, connectors, and servers at runtime. A coding agent, browser agent, or workflow runner may ask an authorization server for a token while holding a URL for a specific tool server. RFC 8707 gives that request a standardized place to carry the intended destination.

The parameter does not grant access by itself. It is an input to authorization-server policy and token construction. The resource server still has to validate the token's audience, the client still has to request the right resource, and the surrounding agent runtime still has to decide whether the action should happen.

Snapshot

Standard: RFC 8707, Resource Indicators for OAuth 2.0, published by the IETF in February 2020.
Parameter: resource, an absolute URI without a fragment component.
Where it appears: authorization requests and access token requests to the authorization server.
Security role: helps the authorization server issue an access token intended for a specific protected resource or set of resources.
Adjacent controls: audience restriction, sender-constrained tokens, protected resource metadata, authorization-server metadata, token exchange, and rich authorization requests.
Agent relevance: MCP clients must include resource in authorization and token requests, and MCP servers must validate that presented tokens were specifically issued for their use.

How It Works

A client includes the resource parameter when it sends an authorization request or token request to the authorization server. RFC 8707 says the value is an absolute URI and must not contain a fragment component. Multiple resource parameters can be used when a requested token is intended for more than one resource.

The authorization server can use the resource value to decide whether the request is acceptable, which token format to issue, which audience value to place in the token, and which effective scope to return. RFC 8707 defines the invalid_target error for an invalid, missing, unknown, malformed, or unacceptable resource.

In an authorization-code flow, the resource requested at the authorization endpoint applies to the authorization grant. A later token request can ask for an access token aimed at a subset of the originally granted resources. RFC 8707 also says the authorization server should audience-restrict issued access tokens to the indicated resources.

RFC 8707 treats resource and scope as separate axes. A token request can ask for a scope and for one or more target services; the effective access is the combination of those requested scopes at those requested resources. The authorization server should downscope the issued token where possible and must tell the client the effective scope when it differs from the requested scope.

Boundary Tests

Not a scope. resource identifies where the token is meant to be used; scope describes the access requested there.
Not OAuth Protected Resource Metadata. Protected Resource Metadata lets a client discover how a resource is authorized. Resource indicators carry the target resource into authorization and token requests.
Not Token Exchange. OAuth Token Exchange issues a new token from an existing token. Resource indicators can help shape the destination of a token, including in exchange-style designs, but they do not express delegation semantics.
Not sender constraint. Sender-Constrained Tokens restrict who can present a token. Resource indicators help restrict where a token is intended to be accepted.
Not user consent. A resource URI can be displayed or logged, but it is not proof that the user understood the resource, approved the action, or authorized a downstream agent workflow.

Current Context

As of this review on July 1, 2026, RFC 8707 remains the stable IETF Standards Track specification for OAuth Resource Indicators. RFC 9700, the OAuth 2.0 Security Best Current Practice published in January 2025, recommends audience restriction to reduce replay of captured access tokens on other resource servers and names RFC 8707 as one mechanism for telling the authorization server the intended resource server.

OAuth Protected Resource Metadata, standardized as RFC 9728 in April 2025, makes the resource side more discoverable. In dynamic agent settings, a client may first learn a protected resource's metadata and authorization server, then use RFC 8707's resource parameter when requesting a token for that resource. OAuth 2.1 remains an Internet-Draft rather than a final RFC as of this review, so current production references should cite RFC 8707, RFC 9700, RFC 9728, and the relevant MCP specification directly.

The Model Context Protocol 2025-11-25 authorization specification turns the resource-indicator pattern into a concrete agent requirement. It says MCP clients must include resource in authorization and token requests, the parameter must identify the MCP server, and MCP servers must validate that tokens presented to them were issued for their use.

Agent Context

The Model Context Protocol makes this concrete. The MCP 2025-11-25 authorization specification says MCP clients must implement Resource Indicators for OAuth 2.0 and include the resource parameter in both authorization requests and token requests. It also says the parameter must identify the MCP server the client intends to use the token with.

That rule addresses a common agent failure mode: a tool URL is discovered at runtime, but the token is minted as if all tools behind the same authorization server are interchangeable. If the requested resource is explicit, the authorization server can issue a token for that destination and the resource server can reject tokens aimed elsewhere.

Resource indicators do not decide whether the agent's instruction is safe. A malicious prompt can still ask an agent to request access to the wrong server, a compromised tool description can try to steer the endpoint, and a legitimate sender can still make an unsafe request. The point is narrower: the token request should carry the destination boundary instead of leaving it implicit in prose, UI state, or model-generated code.

Agent hosts should therefore derive the resource value from a trusted server identity, protected-resource metadata, enterprise allowlist, or preapproved connector record. They should not let arbitrary model-visible text choose the resource URI that controls token audience.

Governance and Safety

RFC 9700, the OAuth 2.0 Security Best Current Practice, recommends audience restriction to reduce replay of captured access tokens on other resource servers. Resource indicators are one way to give the authorization server the destination information needed to make that audience boundary explicit.

Audit trails should preserve the client identifier, requested resource URI, canonicalized resource value, authorization server, granted scope, effective scope returned in the token response, token audience, resource server decision, and any invalid_target failure. In an agent incident, those records answer a basic question: did the agent ask for a token for the server it actually used?

The main governance mistake is treating the resource parameter as decoration. It should drive policy and validation. If the authorization server ignores it, if the resource server fails to validate token audience, or if an agent runtime lets untrusted text choose the resource URI, the boundary collapses back into ambient authority.

Multiple resources require extra care. RFC 8707 allows multiple resource parameters, but a broad multi-resource token can reveal service relationships and enlarge blast radius. For agent connectors, separate resource-specific tokens are often easier to audit and revoke than one token with a cartesian product of scopes and destinations.

Minimum Evidence Record

Client and agent: client ID, agent identity, user or organization authorizing the flow, host application, and run identifier.
Resource: original resource URI, canonicalized resource URI, protected-resource metadata URL if used, and enterprise allowlist or policy source.
Authorization server: issuer, authorization endpoint, token endpoint, authorization-server metadata source, and tenant or realm.
Grant and token: requested scopes, effective scopes, resource parameters sent at authorization and token endpoints, token audience, token lifetime, and sender-constraint method if any.
Validation: resource-server audience check, rejected-token events, invalid_target errors, and mismatch handling.
Agent policy: approval rule, denied resources, prompt-injection or endpoint-spoofing checks, and revocation path.

Defense Pattern

Require a resource for agent tokens. Do not mint broad connector tokens when the client knows the target tool or resource server.
Canonicalize carefully. Use absolute URIs, reject fragments, and define how trailing slashes, paths, ports, and aliases map to resource identities.
Fail closed on ambiguity. Treat missing, unknown, malformed, or policy-forbidden resources as invalid_target rather than silently issuing a broad token.
Validate at the resource server. A resource indicator helps only if the resource server checks token audience before serving the request.
Prefer resource-specific tokens. Avoid multi-resource access tokens for agents unless the use case and audit model require them.
Keep scope separate. Use scopes or Rich Authorization Requests for the action, and resource indicators for the destination.
Pair with sender constraint. Combine audience boundaries with sender-constrained tokens where token replay would create material harm.
Do not trust model-chosen endpoints. Treat resource selection as a policy decision, not as arbitrary text from the current prompt context.

Source Discipline

Claims about OAuth Resource Indicators should identify the exact requested resource URI, authorization request, token request, token audience, effective scope, and resource-server validation behavior. Do not collapse it into OAuth Protected Resource Metadata, OAuth Token Exchange, sender constraint, ordinary scopes, or a legal conclusion that a user consented. Resource says where; scope and authorization details say what; sender constraint says who can present the token.

Use exact source labels. RFC 8707 is the resource-indicator specification. RFC 9700 is the OAuth Security Best Current Practice that recommends audience restriction. RFC 9728 is protected-resource metadata. MCP 2025-11-25 is a protocol specification that requires resource indicators for MCP authorization. A vendor support page may show an implementation gap or product behavior, but it is not the standard itself.

Spiralist Reading

Spiralism reads resource indicators as an address written onto authority. A token should not float as a general permission slip through whatever server an agent happens to meet next.

The address is not trust. It is a boundary. The institution still has to check the request, limit the action, and remember which resource was named when authority changed hands.

Open Questions

Should agent platforms refuse authorization flows when a target resource cannot be derived from a trusted server identity?
How should consent screens explain the difference between scope and resource without burying users in protocol terms?
When multiple resources are requested, should the authorization server issue one token or separate audience-specific tokens?
How should incident reports represent resource selection when model output suggested the endpoint?

Sources

B. Campbell, J. Bradley, and H. Tschofenig, IETF, RFC 8707: Resource Indicators for OAuth 2.0, February 2020; reviewed July 1, 2026.
D. Hardt, IETF, RFC 6749: The OAuth 2.0 Authorization Framework, October 2012.
T. Lodderstedt, J. Bradley, A. Labunets, and D. Fett, IETF, RFC 9700: Best Current Practice for OAuth 2.0 Security, BCP 240, January 2025; reviewed July 1, 2026.
M. B. Jones, P. Hunt, and A. Parecki, IETF, RFC 9728: OAuth 2.0 Protected Resource Metadata, April 2025; reviewed July 1, 2026.
IETF OAuth Working Group, draft-ietf-oauth-v2-1-15: The OAuth 2.1 Authorization Framework, Internet-Draft, March 2026; reviewed July 1, 2026.
Model Context Protocol, Authorization specification, version 2025-11-25; reviewed July 1, 2026.

Return to Wiki