MCP handles authentication and authorization through an OAuth 2.1-based framework added in the 2025 specification revisions, which applies specifically to servers reached over the Streamable HTTP transport rather than local stdio connections. Under this model the MCP server acts as an OAuth resource server, publishing metadata so a client can discover the correct authorization server, and the client is responsible for guiding the user through an authorization code flow with PKCE, then attaching the resulting access token to each request. Dynamic client registration allows a new client to register with an authorization server without manual setup, which matters as the number of MCP clients in use across an organization grows. For local stdio servers, which typically run as a subprocess on the same machine as the client, authentication is usually handled outside the protocol itself, through environment variables or local credentials, since there is no network boundary to cross. Scopes attached to tokens should be kept as narrow as the specific tools require, following least privilege rather than issuing one broad token for an entire system. Nanobase AI, an NVIDIA Inception Program member, implements this OAuth layer for every remote MCP server it deploys for clients.
Who is responsible for what
MCP's authorization framework splits responsibility across three parties, and confusion about which one enforces what is a common source of security gaps in early implementations.
| Party | Responsible for |
|---|---|
| Identity provider / authorization server | Authenticating the user and issuing tokens with the correct scopes and audience |
| MCP client | Discovering the correct authorization server, guiding the user through the authorization flow, and attaching tokens to requests |
| MCP server | Validating incoming tokens, checking their scope and audience, and enforcing per-tool authorization on every call |
The most common mistake is treating a valid, well-formed token as sufficient authorization for any tool the server exposes, when in fact the server still needs to check whether that specific token's scope covers the specific tool being called.
Discovery metadata in plain terms
Rather than hardcoding which authorization server issues its tokens, a compliant MCP server publishes metadata describing where clients should go to authenticate, following the OAuth protected resource metadata pattern. A client fetching this metadata on first connection can locate the correct authorization endpoint automatically, which matters at organizational scale where dozens of internal MCP servers might all sit behind the same identity provider without each one needing custom client configuration. This discovery step happens before any user-facing authorization prompt, and a client that skips it or hardcodes an assumption about the authorization server is more fragile to change.
Token audience and the confused deputy problem
A token's audience claim specifies which resource server it was issued for, and checking that audience matters more than it might seem: without it, a token obtained for one MCP server could potentially be replayed against a different server if that server does not verify the token was actually meant for it. This is a specific instance of the classic confused deputy problem, where a component with legitimate authority is tricked into misusing it on behalf of an untrusted party. A server that validates a token's signature but not its audience is vulnerable to exactly this pattern, accepting a token that was never meant to authorize access to it.
Scope checks belong inside the tool, not just at the door
Establishing a valid, authenticated connection to an MCP server is necessary but not sufficient; the server still needs to check, on every individual tools/call, whether the token's granted scope actually covers that specific operation. A token scoped only for read access to a ticketing system should be rejected by a create-ticket tool even if the same token successfully authenticated the session and passed earlier read-only calls. Implementing this check once at connection time and assuming it covers every subsequent tool call is a shortcut that quietly expands what an under-scoped token can do.
Frequently asked questions
Does stdio transport need any of this OAuth machinery?
No. Stdio-based servers run as a local subprocess on the same machine as the client, with no network boundary to cross, so authentication typically relies on the local operating system's existing access controls and environment-based credentials rather than the OAuth framework built for remote, multi-user access.
What is dynamic client registration and why does it matter here?
It lets a new MCP client register itself with an authorization server automatically rather than requiring manual configuration for every new client an organization introduces, which matters as the number of internal tools and agent platforms connecting to shared MCP servers grows past what manual onboarding can keep up with.
Should scopes be broad and simple or narrow and numerous?
Narrow and numerous, matching the principle of least privilege. A handful of broad scopes covering entire systems inevitably grant more access than most tool calls need, while scopes mapped closely to specific tool categories, such as read-only ticket access versus ticket creation, keep a compromised or over-issued token's usefulness limited.
How Nanobase AI helps
Nanobase AI, an NVIDIA Inception Program member, implements this full authorization stack for every remote MCP server it deploys, including audience validation and per-tool scope enforcement inside the server itself rather than relying on connection-level authentication alone. The broader on-behalf-of token pattern this builds on is covered in sso-oauth-llm-user-data-access.
Ready to discuss your project? Contact Nanobase AI or email hello@bumu.tech.