A client is requesting an access token to use with the MCP server at https://mcp.example.com/mcp. How must it identify the intended server during the OAuth flow?
Select an answer to reveal the explanation.
Short Explanation
The resource parameter is the "deliver to" line on the token's envelope. You put the server's exact address on it at both stops, the authorization request and the token request. And you send it every time, whether or not the authorization server says it understands it.
Full Explanation
MCP clients must implement Resource Indicators for OAuth 2.0, RFC 8707, to state the target resource for which a token is requested. The resource parameter must be included in both authorization requests and token requests, must identify the MCP server the client intends to use the token with, and must use that server's canonical URI. Canonical URIs include the scheme and may include a port or path when needed to identify the server, so https://mcp.example.com/mcp is valid, while a value missing its scheme or carrying a fragment is invalid; clients should provide the most specific URI they can and should generally omit a trailing slash. Clients must send the parameter regardless of whether the authorization server supports it. Binding the token to a resource lets the MCP server validate audience and stops a token minted for one server being replayed at another. Sending it only in the token request fails because the requirement covers both requests; scope does not identify the target server. Sending audience with a bare host fails by concept: the mechanism is the resource parameter, and a value without a scheme is not a valid canonical URI. Sending it only when advertised fails because the specification says to send it regardless of support. Exam caveat: some authorization servers may ignore it, but the client obligation stands. Operational check: capture both requests and confirm each carries the URL-encoded resource value.