Concept card

MCP Authorization — OAuth 2.0 + Tier-Based API Gating

As of 2026-07-24T14:00:00Z

Edited by Cédric-Olivier Mâry, sole editor and publication director — 27 years in the SAP ecosystem. How these pages are produced, and where automation is used.

What is MCP Authorization — OAuth 2.0 + Tier-Based API Gating?

MCP's 2025-06-18 spec mandates OAuth 2.1 for HTTP transport, but identity alone doesn't gate access — commercial servers need a tier-gating layer that returns -32601, never -32603, to avoid leaking which paid tools exist.

The MCP specification revision of June 2025 ships a formal authorization model for the Streamable HTTP transport. The stdio transport runs in-process and trusts the operating-system process boundary, so it needs no external authentication layer at all. The HTTP model is built on OAuth 2.1, the consolidated and security-hardened profile of OAuth 2.0, with PKCE mandatory for every client, dynamic client registration per RFC 7591, and resource indicators per RFC 8707. A server exposes a discovery document at a well-known path that points clients at its authorization server; clients run the authorization-code flow with PKCE and present a bearer token on every JSON-RPC request. Resource indicators bind a token to one specific MCP server, which is what stops a token issued for one service being replayed against another.

Why It Exists

MCP's original trust model was stdio-native: one client, one server, one operating-system user boundary, with authentication delegated entirely to whatever already controls process spawning on that machine. That model collapses the moment a server is exposed over a network, to multiple agents, multiple tenants, or as a metered commercial API. Without a standard authorization layer, a network-reachable MCP server has no way to know who is calling, what they are entitled to, or how to reject a call to a premium tool without leaking that the tool exists. The June 2025 specification closes that gap by mandating OAuth 2.1 wherever MCP runs over HTTP.

The Two-Layer Pattern For Commercial Servers

Why it matters

stdio needs no auth (OS boundary), but any network-exposed MCP server must run OAuth 2.1 with PKCE, dynamic client registration (RFC 7591) and resource indicators (RFC 8707) to bind tokens to one server.
Tier gating translates identity into a tool subset: a free Discover tier sees find_firms public fields only, Buyer adds full profiles, Practice adds search_news, Recruiter adds opportunity tools.
Returning -32603 instead of -32601 for an out-of-tier tool call leaks the existence of premium tools to an unauthenticated caller.

Key points

OAuth 2.1 + PKCE for HTTP transport (stdio is in-process, OS-trusted); spec rev 2025-06-18 mandates PKCE for public clients.
Discovery — /.well-known/oauth-protected-resource points clients at authorization server; dynamic client reg via RFC 7591.
Bearer token in Authorization header on every JSON-RPC request; resource indicators (RFC 8707) bind tokens to a specific MCP server.
Tier-gating layer — translate token identity into tool subset; non-entitled calls return -32601 method not found, not -32603 (leakage risk).
Stripe Meters + rate-limit Worker — usage billing layered on top of OAuth (the platform charter Year-2 model; §20.5 Cloudflare substrate).
MCP Authorization — OAuth 2.0 + Tier-Based API Gating is mastered only when it changes a named buyer decision.
Start with the semantic contract and control model before demonstrating the tool.
Use current SAP, analyst, study, KG, and news signals as evidence, not decoration.
Separate verified facts from directional trends and modeled assumptions.
Define owner, metric, threshold, support path, and rollback before scaling.

Terms used on this page

OAuth 2.1 with PKCE: The consolidated OAuth profile MCP HTTP transport adopts; PKCE (Proof Key for Code Exchange) is mandatory for public clients and replaces the implicit and password grants, eliminating two long-standing classes of token-theft vulnerability.
Resource indicator (RFC 8707): An OAuth extension that binds an access token to a specific protected resource (the MCP server URL); a token issued for server A cannot be replayed against server B even if both share an authorization server.
Tier-gating layer: The server-side check, layered above OAuth, that maps an authenticated identity to the subset of tools that the user's paid tier is entitled to call; non-entitled calls return -32601 (method not found), never -32603 (which would leak the existence of paid tools).
Dynamic client registration (RFC 7591): The OAuth extension that lets an MCP client register itself with the authorization server programmatically at first contact, removing the manual client-id provisioning step that would otherwise block self-service agent onboarding.
Decision owner: The accountable person who accepts the trade-off and funds the next action.
Semantic contract: The shared definition of business terms, metrics, entities, and access rules used by tools and teams.
Control plane: The layer that applies policy, access, lineage, monitoring, and escalation across the operating model.
Evidence grade: A label that separates verified fact, directional signal, modeled assumption, and field observation.

Sources

Full card available to members. What the full card adds: the full decision framework · the SAP vs Snowflake / Databricks / Fabric comparison · the common pitfalls and their fix · the cheat sheet · the architecture schemas · the code blocks · the facts worth quoting.

Open in the app →