A team is mapping MCP authorization for a remote Streamable HTTP server onto OAuth 2.1 roles. Which mapping matches the authorization specification?
Select an answer to reveal the explanation.
Short Explanation
Map it like a concert: the venue (MCP server) checks tickets, you (the MCP client) present one, and the box office (authorization server) prints them. Don't get thrown by the option saying the venue must also run the box office; it may, but it doesn't have to.
Full Explanation
The authorization specification defines three roles. A protected MCP server acts as an OAuth 2.1 resource server, accepting and responding to requests that carry access tokens. An MCP client acts as an OAuth 2.1 client, making protected resource requests on behalf of a resource owner. The authorization server interacts with the user if necessary and issues access tokens for use at the MCP server; its implementation is out of scope, and it may be hosted with the resource server or be a separate entity. The MCP server advertises its authorization servers through Protected Resource Metadata, which it must implement. Calling the MCP server the authorization server and the user agent the issuer fails because the browser only carries the user through the authorization step; it never issues tokens. Reversing the roles so the client is the resource server fails by concept: the client requests protected resources and the server protects them, not the other way round, and the host does not issue tokens. Saying the MCP server must be both resource and authorization server fails because the specification explicitly allows them to be separate, and the resource owner is the user, not the client. Exam caveat: authorization is optional overall, and HTTP-based implementations should conform when they support it. Operational check: fetch the server's Protected Resource Metadata and confirm authorization_servers lists at least one issuer.