A company is deploying a remote MCP server and asks who should run the OAuth authorization server that issues its access tokens. What does the MCP specification say about this role?
Select an answer to reveal the explanation.
Short Explanation
Picture a stadium: the gate checks tickets, but the box office can be in the same building or across town. MCP only cares that you can find the box office from the gate, so don't fall for answers that force the two together.
Full Explanation
The authorization specification defines three roles. The MCP server is an OAuth 2.1 resource server that accepts access tokens; the MCP client is an OAuth 2.1 client making requests on behalf of a resource owner; and the authorization server interacts with the user if needed and issues tokens for use at the MCP server. The spec states that the authorization server's implementation details are beyond its scope and that it may be hosted with the resource server or be a separate entity, such as an enterprise identity provider. The MCP server tells clients where to find it through Protected Resource Metadata, which can point to any issuer, so nothing requires the server to embed its own. PKCE binds the code exchange to the client that started it; it says nothing about where the issuer runs, and a client never operates the authorization server. The MCP Registry handles namespace verification for publishing metadata and plays no part in runtime token issuance. Exam caveat: whatever the topology, clients must still discover the issuer through metadata and send the resource parameter. Operational check: fetch the server's protected resource metadata, confirm its authorization_servers entry names the intended issuer, and verify that issuer's metadata advertises the expected endpoints.