A token audience says which server a token is meant for. In MCP, the client sends a resource parameter naming the MCP server, and the server must check that the token was issued for it. This stops a token stolen from one service from working at another.
The two halves
The MCP authorization specification splits the job.
The client side: clients must implement Resource Indicators for OAuth 2.0 (RFC 8707). The resource parameter must be included in both the authorization request and the token request, and it must identify the MCP server using its canonical URI. Clients must send it whether or not the authorization server is known to support it.
The server side: MCP servers must validate that access tokens were issued specifically for them as the intended audience. Invalid or expired tokens get an HTTP 401. Servers must not accept or transit any other tokens.
What a canonical URI looks like
The specification gives valid examples such as https://mcp.example.com/mcp and https://mcp.example.com:8443. It lists mcp.example.com with no scheme and anything with a fragment as invalid. It also advises using the form without a trailing slash unless the slash means something for that resource.
Why this matters for agents
Agents often hold several tokens, one per connected service. If every MCP server accepted any valid token from the same identity provider, a compromise of one low value server would expose tokens that work on a high value one.
Audience binding makes each token useful at one place. The specification calls this out as a fundamental OAuth security boundary and says failing to verify the audience lets attackers reuse legitimate tokens across services.
What to check in your server
- Parse the token and confirm the audience claim contains your server identifier, as RFC 9068 describes for JWT access tokens.
- Reject tokens that lack your identifier, even if the signature is valid.
- Never forward the incoming token upstream. If you call another API, get a separate token for it.
- Keep access tokens out of query strings. The specification says they must not appear in the URI.
- Prefer short lived access tokens, and rotate refresh tokens for public clients, which the specification requires.
Related controls the same page requires
PKCE for the authorization code flow, exact redirect URI matching against registered values, and HTTPS for all authorization server endpoints. Those, plus audience binding, form the baseline.
Where Safeguard fits
Safeguard includes agent identity so each agent has its own identity in the system rather than borrowing a shared credential. Audience checks in your MCP server remain your responsibility.
Quick check
What if my authorization server does not support the resource parameter?
The specification still tells clients to send it, and tells servers to validate the audience. Binding only works fully when the authorization server supports it, so check that support when choosing one.
Sources
Last reviewed: 19 October 2026.
