Wiki · Concept · Last reviewed June 25, 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 token can be shaped and audience-restricted before an agent uses it.

Category: Concept Updated: June 25, 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 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.

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.

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, and a resource server can still be compromised. 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.

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.

Defense Pattern

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.

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

Sources

Return to Wiki