The OAuth Model You Already Know
The authorization model your IDAM instincts are built on has a clean three-party structure. An Authorization Server issues tokens that carry scopes — bounded declarations of what the bearer is permitted to do. A Resource Server enforces those scopes at the point of access. The client requests the minimum necessary, the AS decides what to grant, and the RS doesn't care about the client's intentions — it checks the token and enforces the scope. Least privilege is structural, not aspirational.
That model has twenty years of implementation experience behind it. When a government security architect asks whether something "supports OAuth," they're asking whether that structure is present: scoped tokens, server-side enforcement, a trust hierarchy they can reason about.
Where MCP Uses OAuth Vocabulary
The Model Context Protocol specification, published by Anthropic and now maintained under the MCP organization, does incorporate OAuth 2.1 as its authorization framework. MCP servers can act as OAuth resource servers. Clients obtain tokens. The vocabulary is familiar enough that a seller with solid IDAM background will feel oriented.
That feeling is the problem.
The Break Points
Two gaps in the current MCP authorization model are documented and actively discussed in the specification community, and neither one is subtle.
The first is dynamic client registration. The MCP spec permits — and in some flows, relies on — clients registering themselves with an authorization server at runtime, following RFC 7591. In a controlled enterprise environment, this is a trust boundary question: who decided this client was allowed to register? In a federal deployment context, where every integration point typically requires explicit approval and the trust hierarchy is auditable by design, dynamic self-registration without pre-approval is not a minor implementation detail. It's a procurement conversation. The community has flagged this in the modelcontextprotocol/specification GitHub repository — raised by practitioners with enterprise deployment experience, not as a fringe objection but as a structural gap between the spec's current state and what agencies actually require.
The second gap is scope enforcement at the tool level. An MCP server exposes tools — discrete callable functions that an AI agent can invoke. The OAuth authorization in the current spec operates at the MCP server level, not at individual tool invocations. That means a token authorizing access to an MCP server may, depending on implementation, authorize access to every tool that server exposes. The granularity the RS-enforces-scopes model implies — where a client requesting read access can't invoke a write operation — doesn't automatically carry through to the tool layer. Whether it does depends on how the MCP server is implemented. The spec makes no guarantee.
For a government buyer whose data classification requirements mean that read access to one dataset and write access to another are categorically different authorization decisions, this is a live concern, not a theoretical one.
The Spec Is Moving
The MCP specification is under active development. Anthropic and the broader contributor community are aware of these gaps — the GitHub issues are public, the discussion is substantive, and the authorization model is explicitly flagged as evolving in the spec itself. That's an honest answer, and it's more useful than either "OAuth is OAuth" or "MCP security is immature."
What to Do Tuesday
When a buyer asks whether your MCP server supports OAuth, the accurate answer is: "Yes, and let me be specific about what that covers." Then ask them what they're actually trying to govern — is it which clients can connect? Which tools an agent can invoke? What data those tools can access? Those are three different questions, and the current MCP authorization model answers them with varying degrees of completeness.
If their security architect follows up on dynamic client registration or tool-level scope enforcement, don't improvise. Bring in your SE, reference the spec directly, and be honest that the community is actively working through these questions. That posture — technically fluent, honest about the spec's current state — is what earns you the next conversation with the architect. The seller who can give a precise answer to a precise question is the one who stays in the room when the technical review starts.