RFC 8707: Resource Indicators for OAuth 2.0
IETF Proposed Standard adding a `resource` parameter so a client can tell the authorization server which protected resource a token is meant for (audience binding).
Tags
Description
The MCP authorization spec requires clients to send the resource parameter (RFC 8707) in authorization and token requests, identifying the target MCP server.
Related
- MCP Authorization (OAuth 2.1 for MCP): The MCP specification's transport-level authorization flow for HTTP-based MCP servers, based on a subset of OAuth 2.1 and related RFCs.
- RFC 9728: OAuth 2.0 Protected Resource Metadata: IETF Proposed Standard defining a metadata document a protected resource publishes (at /.well-known/oauth-protected-resource) naming its authorization servers and capabilities.
Guides & comparisons
- Add OAuth authorization to your own MCP server (Guide): A server-side walkthrough of the MCP 2026-07-28 authorization spec: publish RFC 9728 protected resource metadata, answer 401 and 403 challenges, verify JWT audience per RFC 8707, enforce per-tool scopes, and never pass tokens through. Tested with the MCP TypeScript SDK v2.
- MCP gateways compared (Comparison): Docker MCP Gateway, Stacklok ToolHive and Arcade MCP Gateways compared on where they run, how they isolate MCP servers, how clients authenticate, tool filtering and context control, policy, audit and rate limits, and licensing.
Sources
- https://datatracker.ietf.org/doc/rfc8707/
- https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization
Machine-readable
- JSON
- Markdown
- Source file on GitHub (edit via pull request)