OAuth vs MCP for Enterprise Access: Where Avatier Governs the Gap

OAuth and MCP are not competing choices. MCP (the Model Context Protocol) is an open protocol that lets AI assistants reach tools and data through MCP servers, and OAuth is the authorization framework MCP's authorization specification builds on for HTTP-based servers. OAuth answers whether this client may call this server, on this user's behalf, with these scopes. Identity governance still has to answer which human, which agent, which approved capability, which policy, and with what evidence.

That split matters once Claude, Microsoft Copilot, or another MCP-compatible assistant is connected to systems that change identity state: resetting passwords, adding people to groups, disabling accounts, approving access. The token flow can be implemented perfectly and still leave the most important question unanswered: should this specific action happen?

This article compares the two, walks through how MCP authorization uses OAuth (checked against the current specification), and shows where scopes stop. For OAuth fundamentals, see the OAuth 2.0 guide for identity governance teams and the OAuth 2.0 vs OpenID Connect reference.

OAuth vs MCP at a glance

The quickest way to see why "OAuth vs MCP" is the wrong framing is to put them side by side. They sit at different layers and answer different questions.

Dimension	OAuth (2.0 and the 2.1 draft)	MCP (Model Context Protocol)
What it is	An authorization framework for obtaining limited access to a protected resource	An open protocol for connecting AI applications to external tools and data
Who defines it	The IETF. OAuth 2.0 is RFC 6749, and OAuth 2.1 is still an active Internet-Draft	The MCP project, in dated specification revisions. The current one is 2026-07-28
What travels	Authorization requests, codes, and access tokens	JSON-RPC 2.0 messages for tools, resources, and prompts
Main roles	Client, resource server, authorization server, resource owner	Host, client, server
Unit of permission	Scope strings defined by the authorization server	Tools the server chooses to expose
Question it answers	May this client access this resource, within these scopes?	What can this AI application discover and invoke?
How they connect	Supplies the token model MCP uses for HTTP-based servers	Maps its server to an OAuth resource server and its client to an OAuth client
What it leaves open	Whether one specific business action is allowed	Whether the invoked tool should run for this person, now, under policy

Neither protocol decides whether a particular identity action is permitted under enterprise policy, and neither produces business evidence of the outcome. That is the governance layer.

OAuth and MCP work at different layers. MCP authorization builds on OAuth 2.1, and neither one decides per-action policy on its own.

What each one is

OAuth is an authorization framework. The OAuth 2.1 draft opens by saying it "enables an application to obtain limited access to a protected resource," either on behalf of a resource owner or on the application's own behalf. The result is an access token, which the draft defines as "a string representing an authorization issued to the client." What that authorization covers is expressed as scope: space-delimited, case-sensitive strings defined by the authorization server. OAuth 2.1 is meant to replace OAuth 2.0 (RFC 6749). It makes PKCE part of the default authorization code flow and drops the implicit grant, but it is still a draft, not a published RFC.

MCP is a protocol for AI applications. Anthropic open-sourced it in November 2024 as "a new standard for connecting AI assistants to the systems where data lives." The specification describes MCP as "an open protocol that enables seamless integration between LLM applications and external data sources and tools." It uses JSON-RPC 2.0 messages between three roles:

• Hosts: the LLM applications that start connections
• Clients: the connectors inside the host
• Servers: services that provide context and capabilities

Servers can offer three features:

• Resources: context and data for the user or the model
• Prompts: templated messages and workflows
• Tools: functions the model can execute

Tools matter most for access decisions. The spec calls them model-controlled: the language model can discover and invoke them based on context and the user's prompts. It also says there should always be a human in the loop with the ability to deny tool invocations. A tool call is a tools/call request naming the tool and its arguments.

OAuth proves a client may reach a resource. MCP defines what an AI application can do once it gets there. The two meet at the MCP server.

How MCP authorization uses OAuth

This section follows the MCP authorization specification, revision 2026-07-28. Details change between revisions, so check the one you implement.

Transport decides the approach. Authorization is optional in MCP. When supported, HTTP-based implementations should conform to the spec, while local STDIO implementations should instead get credentials from the environment. The flow below covers remote, HTTP-based servers, the kind an enterprise would share across many users.

Roles map directly onto OAuth. In the spec's words, a protected MCP server "acts as an OAuth 2.1 resource server," and 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 and issues tokens, and its implementation is outside the spec's scope. That's the hook for enterprises: it can be an identity provider you already run, provided it meets the spec's requirements, such as the discovery metadata and PKCE support MCP clients check for.

The flow runs in eight steps:

1. Discovery starts with a 401. A request without a token gets HTTP 401. The server points to its protected resource metadata either with a resource_metadata value in the WWW-Authenticate header or at a well-known URI, and clients must support both. MCP servers must implement RFC 9728 Protected Resource Metadata, and clients must use it to find the authorization server.
2. The client reads authorization server metadata. Authorization servers must offer OAuth 2.0 Authorization Server Metadata (RFC 8414) or OpenID Connect Discovery, and clients must support both.
3. The client gets a client ID. Options are Client ID Metadata Documents (which clients and servers should support), pre-registration, or Dynamic Client Registration, which the current revision marks as deprecated.
4. Scopes come from the server's challenge. Servers should include a scope parameter, and clients should request only the scopes they need.
5. The request uses PKCE and a resource indicator. Clients must implement PKCE, using S256 when technically capable, and must include the RFC 8707 resource parameter in both the authorization and token requests, naming the MCP server's canonical URI.
6. The user authorizes, and the client validates the issuer. Before sending the authorization code to any token endpoint, clients must apply the RFC 9207 issuer check. When the response carries an iss value, it has to match the issuer the client recorded from validated metadata.
7. The client exchanges the code for an access token. It sends the token as a bearer token in the Authorization header on every HTTP request, never in the query string.
8. The server validates audience. MCP servers must validate that tokens were issued specifically for them, and must not accept or transit any other tokens.

A token opens the channel and a tool call names the action. Governance then decides the action and writes the evidence.

Two details matter most for enterprise identity. The first is step-up authorization. When a token lacks scope, the server should return HTTP 403 with an insufficient_scope error naming the required scopes, and a client acting for a user should try to get a new token. The spec's security best practices build on this: start with a minimal scope set and elevate only when a privileged operation is first attempted.

The second is the ban on token passthrough. An MCP server calling an upstream API may act as an OAuth client to it, with a separate token from the upstream authorization server. It "MUST NOT pass through the token it received from the MCP client." Passthrough lets clients bypass controls and leaves the server unable to tell clients apart, which the best practices say makes incident investigation and auditing harder. For the operational side, see how to secure MCP servers.

Is MCP a replacement for OAuth, or for API access?

MCP replaces neither. It uses OAuth for authorization, and an MCP server can sit in front of APIs rather than in place of them.

MCP vs OAuth. MCP's authorization spec is built from OAuth parts: the OAuth 2.1 draft, bearer token usage, authorization server metadata, resource indicators, protected resource metadata, and issuer identification, among others. It implements "a selected subset of their features" and makes several of them mandatory, so an MCP deployment is a more specific OAuth deployment, not a looser one. If someone says MCP removes the need for an OAuth strategy, the spec says otherwise for any HTTP-based server that supports authorization.

MCP vs API access. The spec describes tools as letting models "interact with external systems, such as querying databases, calling APIs, or performing computations." One pattern is an MCP server that wraps existing APIs and presents them as tools. That creates two hops:

• Assistant to MCP server. The MCP client presents a token issued for the MCP server.
• MCP server to upstream API. The MCP server uses its own, separate credential for the upstream API.

The second hop is easy to overlook. If the MCP server reaches the directory with one broadly privileged service credential, every user's request runs with that credential's rights, and the user's scopes on the first hop say nothing about it. The passthrough ban doesn't stop a server from doing too much with a legitimate credential of its own. The MCP identity governance guide calls this the god-mode service account problem. Treat MCP as a new client surface on your existing APIs, governed like a portal or the help desk, not as a way around them.

What OAuth scopes don't capture for agent actions

A scope describes an access range. Agent actions need decisions about specific outcomes. RFC 9396, which defines OAuth rich authorization requests, explains that the scope parameter "is sufficient to implement static scenarios and coarse-grained authorization requests," but "it is not sufficient to specify fine-grained authorization requirements." MCP's own best practices list "treating claimed scopes in token as sufficient without server-side authorization logic" as a common mistake, and note that a single omnibus scope "masks user intent per operation."

Here is an illustrative MCP tool call. It follows the spec's tools/call shape, but the tool and arguments are invented, and like the spec's examples it omits required request metadata for brevity. It is not a real product schema:

{
  "jsonrpc": "2.0",
  "id": 7,
  "method": "tools/call",
  "params": {
    "name": "disable_account",
    "arguments": {
      "target_user": "k.osei",
      "reason": "Contract ended; offboarding ticket HR-3317"
    }
  }
}

Assume the token behind this call is valid, issued for this server, with a scope covering account changes. Here is what it can't tell you.

Per-action policy. The scope says the client may make account changes. It doesn't say whether the requester may act on k.osei, whether k.osei is on a legal hold, or whether this change breaks a separation-of-duties rule. Those depend on the target and the context of this one call. RFC 9396 lets a client describe finer-grained requests, but something still has to evaluate enterprise policy against each one.

Delegated authority. OAuth represents a client acting on behalf of a resource owner. It doesn't say whether that person has authority over the target. A manager may disable a direct report's contractor account; a peer probably may not. An assistant should never hold more authority than the person it acts for, and that comes from the identity system's model of who may act on whom, not from the scope string.

Business approvals. OAuth consent is the resource owner letting a client access something. A business approval is a different person agreeing that a specific change should happen, such as an application owner approving access or a manager confirming a termination. MCP says a human should be able to deny tool invocations, which is a real safeguard. But confirmation by the person asking is not approval by the person accountable.

Audit evidence. Token logs show a token was issued and used, and the MCP spec says clients should log tool usage for audit purposes. Neither is an evidence record telling an auditor which human asked, which agent called, what authority was in effect, which policy applied, what ran, and what resulted, including denials.

A valid token is not a permitted action. Scopes name an access range, and governance decides each outcome.

The governance layer: five questions every agent action must answer

If OAuth and MCP authorization open the channel, governance decides each action that travels through it. A governed deployment can answer five questions for every identity action an assistant takes.

Question	What OAuth and MCP authorization provide	What governance has to add
Which human?	A token issued after a user authorized the client	The accountable person, resolved from a real authentication event and tied to their entitlements
Which agent?	A client ID for the MCP client	The initiating assistant or experience, recorded, and allowed only where approved
Which approved capability?	The tools the server exposes, and the scopes that gate them	A curated catalog of narrow identity capabilities with owners and known blast radius
Which policy?	A scope check at the server	Per-action evaluation against who-may-act-on-whom, separation of duties, approvals, and context
With what evidence?	Token and tool-usage logs	A structured record of each outcome, allowed or denied, written when it happens

The principle behind the table: the assistant is the interface, never the authority. The decision belongs to a deterministic identity system behind the tool, because models can be steered by content they read. If authority lives in the model or the system prompt, anything that influences the model can escalate privilege. If it lives behind the tool, a manipulated assistant can only request what its user could already do. The agentic identity hub covers how agents themselves are registered and scoped.

A short evaluation checklist for any MCP deployment that touches identity:

1. Confirm the OAuth basics: PKCE, resource indicators, audience validation, short-lived tokens, no passthrough.
2. Check the second hop: which credential the server uses upstream, and whose authority each request runs on.
3. Review the tool catalog: narrow, owned capabilities, not generic directory write.
4. Find where policy is evaluated: in the identity system on every call, not in a prompt.
5. Map sensitive actions to approvers you already use for portal and help desk requests.
6. Inspect the evidence for completed and denied actions alike.

What Avatier ships toward this pattern

Avatier's published materials describe controls for its MCP connectors that line up with the five questions above. They don't describe the OAuth or token mechanics of a deployment.

Approved capabilities, not raw access. Avatier's launch materials state that AI assistants do not receive unrestricted access: every request must invoke an approved Avatier capability. Avatier Actions is an MCP connector that exposes more than 50 identity outcomes as MCP tools across eight modules: Password Management, Help Desk, Lifecycle Management, User Management, Group Management, Access Governance, Workflow Approval, and Reports. That is a defined set of approved capabilities, not unrestricted access.

Controls on every request. Every request remains subject to authentication, authorization, delegated authority, policy enforcement, and audit controls, and Avatier determines whether an identity action is permitted and records what occurred. Outcomes run through the customer's existing policies, approvals, and roles. The assistant is the interface, never the authority. The module list includes related actions: User Management includes proxy of authority, and Workflow Approval covers pending requests and history.

Permissions you already govern. Setup is one administrator connection. Permissions are inherited from the identity platforms customers already run, including Microsoft Entra ID, Active Directory, Okta, and Ping, and Avatier operates alongside them rather than replacing them. There is no per-user setup and no new permissions model. Avatier also works with existing investments such as SailPoint, Saviynt, ServiceNow, and Moveworks.

Evidence on every outcome. Avatier Ledger, a separate MCP connector, turns every outcome into evidence and every report into a question. In the words of Avatier CISO Sam Wertheim, Ledger records who asked, what ran, under whose authority, and what policy allowed it, for every action, human-initiated or agent-assisted. Each Secure Outcome records the identity involved, the initiating agent or experience, the authorization context, the policy applied, the action taken, and the final result. Persona Briefings shape the same evidence for a CISO, a CFO, or the security team. The AI agent audit trail guide covers the record in detail.

Where it runs, and how it's priced. The connectors work inside Claude, Claude Code, Microsoft Copilot, Avabot, and any MCP-compatible assistant, as part of Avatier Identity Anywhere 2027™. They are priced under Pay Per Identity Action™, meaning customers pay only for completed, verified, policy-compliant outcomes. Getting started is free, deployment services are included, and a 45-day money-back guarantee applies. What is Pay Per Identity Action explains the model.

The Avatier Trust Center publishes the security posture behind the platform, including that Avatier is SOC 2 Type II audited with no exceptions noted and ISO/IEC 27001:2022 certified. The MCP-native platform is previewed at Avatier Identity Anywhere 2027™. Password and reset controls are covered on Credential Governance™, including Assisted Reset, where the identity challenge routes to the user's own device and the help desk agent only sees pass or fail. The wider platform is at avatier.com.

What this approach does not solve

It doesn't replace a correct OAuth and MCP implementation. Audience validation, PKCE, resource indicators, issuer checks, secure token storage, and the passthrough ban still have to be right at the protocol layer. Avatier's published materials describe the controls applied on every request, not the token mechanics of each deployment, so ask for those specifics when you evaluate any MCP connector, Avatier's included.

It doesn't govern MCP servers you don't control. If a team connects an assistant to a third-party MCP server that acts on a SaaS application directly, your identity governance never sees those calls. Server allow-listing, supply-chain vetting, and control over which connectors assistants may load reduce that risk. They don't bring someone else's server inside your policy boundary.

It doesn't stop prompt injection or tool poisoning. Keeping authority out of the model limits what a manipulated assistant can achieve. It can't prevent a manipulated assistant from making an allowed but harmful request, leaking data the user can already see, or misreporting what it did. The MCP spec itself says clients must treat tool annotations as untrusted unless they come from a trusted server. Defense in depth still applies.

It doesn't fix entitlements that are already wrong. Delegated authority caps an assistant at what the requester holds. If the requester has accumulated excess access, the assistant inherits it. Access reviews matter more once assistants can act, not less.

The standards are still moving. OAuth 2.1 is still an IETF Internet-Draft, and the MCP authorization spec changes between dated revisions. The current revision, for example, deprecates Dynamic Client Registration in favor of Client ID Metadata Documents. Pin the revision you implement, and re-check it when you upgrade.

Within those limits, the model is simple. OAuth proves the client may knock. MCP defines what it can ask for. Governance decides each answer and keeps the receipt. For the controls that make that decision reliable, continue with MCP identity governance.