OAuth 2.1 Authorization Server Selection and Configuration for MCP Gateway Deployments

An enterprise MCP gateway with OAuth 2.1 and tool-level RBAC needs an authorization server that works with it, permissions tied to the identity roles already in place, and an audit trail for every tool call. Which authorization server is chosen and how it is set up decide whether those controls work across real AI clients. The right choice must meet the MCP revision being deployed and do what the gateway cannot, beyond providing an OAuth login screen.

Why MCP's OAuth 2.1 mandate is more demanding than most teams expect

“Use OAuth” sounds like a checkbox. MCP names a stack of protocols with distinct jobs, including OAuth 2.1 with PKCE S256, RFC 9728 Protected Resource Metadata, RFC 8707 Resource Indicators, and RFC 7591 Dynamic Client Registration. PKCE protects authorization codes, metadata enables discovery, and Resource Indicators restrict where tokens can be used. An identity provider that handles login can still leave these requirements unmet.

Registration also depends on the specification revision. The June 2025 revision made Dynamic Client Registration a SHOULD to support clients that need to register themselves. The November 2025 revision introduced Client ID Metadata Document, or CIMD, as the preferred mechanism and made DCR optional for backward compatibility.

The security boundaries are less negotiable. MCP forbids token passthrough and requires separate tokens for upstream APIs. The specification also documents a confused-deputy risk when a proxy combines a static upstream client ID, dynamic registration, and cached consent. These are reasons to inspect protocol behavior.

How the authorization architecture changed as MCP moved from local tooling to enterprise infrastructure

The March 2025 revision brought OAuth 2.1 to remote servers in place of the earlier advice to use ad-hoc API keys. It also introduced Streamable HTTP as a first-class transport and RFC 8414 authorization server metadata discovery. Token endpoint discovery replaced clients' dependence on hardcoded URLs.

The June 2025 revision completed the architectural split. MCP servers became OAuth Resource Servers, while dedicated authorization servers took responsibility for token issuance and client management. Protected Resource Metadata became mandatory, giving clients a route from the protected server to its authorization service. Server authors no longer needed to build the whole OAuth system, but platform teams now had to choose one.

That timeline provides a useful deployment audit. A server built against the March 2025 specification may lack later requirements, with acceptance of plain PKCE or a 401 response without a WWW-Authenticate header serving as clear warning signs. Across a fleet, the split also creates a need to manage trusted authorization servers, client registration, and token policy consistently. Moving token issuance out of the server does not make that responsibility disappear.

How do you enforce OAuth policy and tool-level RBAC at an MCP gateway?

A gateway provides one enforcement point in front of many MCP servers. It validates tokens, routes requests according to scopes, and produces a unified audit log. Backend servers can then omit OAuth code if they accept connections only from the trusted gateway IP range.

That enforcement must reach beyond URL endpoints. Enterprise MCP access depends on the agent, the user session, the tool, its parameters, and the prompt context. A gateway can filter tool discovery by per-agent permissions and use annotation metadata to block tools not marked readOnly. Access to a server is not permission to use everything inside it.

Short-lived, delegated tokens support scoped access, while token exchange supports downstream calls without forbidden passthrough. Registration support must also match the client population. Speakeasy's enterprise AI control plane combines OAuth policy enforcement with visibility into which agents access which tools, illustrating the governed layer that sits above the protocol machinery.

The six criteria that determine whether an authorization server actually fits MCP

The first criterion is RFC coverage for the deployed revision and clients. Score PKCE S256, Resource Indicators, Protected Resource Metadata integration, and registration support separately. DCR matters for clients that self-register, while support for CIMD shows that a server follows the November 2025 revision. Without a compatible registration path, teams inherit manual client registration or shim infrastructure.

The second criterion is downstream token exchange. A gateway that calls upstream APIs needs separate tokens, and on-behalf-of exchange lets it make those calls without asking the user to authenticate again each time. The third criterion is short-lived, narrowly scoped issuance. Scopes should grant access only to individual tools, such as mcp:tools/database.queryScopes should grant access only to individual tools, such as mcp:tools/database.query.

The fourth criterion is enterprise identity integration, including SAML or OIDC, SCIM provisioning, and audit records that join the existing identity trail. The fifth is a standalone path that adds MCP authorization without forcing a migration of users and login systems. The sixth is framework integration, including FastMCP, Cloudflare Workers, the official Anthropic SDKs, and Vercel's MCP packages. These criteria check for different ways things can fail, so good enterprise SSO cannot make up for a lack of client discovery or registration.

How managed identity platforms compare against the six criteria

WorkOS is a starting point when the choice between replacing identity and retaining it matters. WorkOS describes support for DCR, PKCE, Resource Indicators, Protected Resource Metadata, and CIMD. AuthKit provides the full-platform path, with integrations for FastMCP, the official MCP SDKs, and Cloudflare Workers. WorkOS Connect instead handles MCP discovery, registration, token issuance, and consent in front of an existing identity system.

Auth0 by Okta is a strong candidate when downstream delegation and enterprise identity integration dominate the decision. Auth for MCP reached general availability in May 2026 with CIMD registration, on-behalf-of token exchange, and Resource Parameter Compatibility Mode. Its SAML/OIDC and SCIM support addresses the enterprise integration criterion. Stytch Connected Apps offers another standalone route, providing OAuth 2.1 with PKCE, DCR, and consent UI over existing CIAM providers. The stated capabilities support a shortlist.

Google's OAuth, GitHub's OAuth, and Microsoft Entra ID do not support DCR out of the box. For clients that depend on DCR, using one as the sole authorization server means maintaining registrations manually or adding a shim. Entra ID paired with Azure API Management can address enterprise integration, but the remaining RFC requirements still need explicit configuration.

Self-hosted authorization servers: when Keycloak or Zitadel is the right answer

Self-hosting is appropriate when data residency, air-gapped environments, or existing on-premises identity infrastructure make managed services impractical. Keycloak and Zitadel are open-source options, with Zitadel taking an OIDC-native approach. The tradeoff is meaningful engineering work to configure and operate the authorization layer.

High-assurance deployments can combine either option with mTLS and OAuth 2.1. In this pattern, both the client and the server present X.509 certificates that are checked against a trusted CA. That authenticates the transport participants, while OAuth scopes constrain their permitted actions. The two controls answer different questions, so a certificate does not replace tool-level authorization. Self-hosting permits this pattern without a managed platform dependency, but does not remove the six evaluation criteria.

How enterprise identity providers fit into MCP authorization through the gateway layer

An enterprise does not need to abandon Entra ID because it lacks DCR. The existing IdP remains the identity backbone, a managed or self-hosted authorization server handles OAuth flows, and the gateway handles missing registration behavior, token validation, scope rewriting, and auditing. The gap is bridged only when those duties are assigned explicitly.

The June 2026 Enterprise-Managed Authorization extension formalizes centralized enterprise access. Users authenticate through the identity provider they already use, and servers that administrators have approved connect automatically without per-server consent screens. Connecting the gateway through OIDC and refreshing tokens automatically lets this model work without re-authentication on every call. Tool-level RBAC should map to Okta groups or Entra ID security groups rather than a separate collection of hand-maintained permissions.

The control-plane pattern turns those identity decisions into runtime enforcement. As one example, Speakeasy provides a governed distribution layer that extends existing IdP roles to MCP access and records policy decisions. The authorization server must still do its part in handling the protocols. A control plane coordinates those responsibilities across the fleet.

Configuration steps that determine whether a spec-compliant setup holds under real client behavior

Start with discovery. The /.well-known/oauth-protected-resource endpoint must be reachable and identify the correct authorization server. The metadata document and the WWW-Authenticate flow must both work, because a bare 401 breaks discovery for clients following that flow. Token validation also needs the authorization server's production JWKS endpoint for public key verification.

Next, enforce PKCE S256 by rejecting plain. This matters for public clients running on desktops, CI runners, and serverless functions where storing a client secret is impractical. Consent must be stored for each client on its own instead of being shared through cached consent cookies. The state parameter must be checked before redirect to guard against confused-deputy and CSRF risks across agent sessions.

Configure scopes such as mcp:tools/database.query and mcp:tools/files.read at tool level. Incorporate annotation metadata, including readOnly, idempotent, and dataClassification, into policy to avoid enumerating every tool. Keep access tokens short-lived, rotate refresh tokens automatically, and configure the gateway to handle refresh transparently. Finally, validate the Origin header on incoming connections and return HTTP 403 when a present origin is invalid. Local servers must bind to 127.0.0.1 rather than 0.0.0.0.

Four deployment topologies and the authorization server configuration each one requires

A single-tenant internal deployment is for teams that share one organization and directory. Use Okta or Entra ID as the identity backbone, with the gateway handling DCR and token validation. Map tool-level scopes to IdP groups. This profile fits internal developer tooling with a bounded organizational audience.

In a multi-tenant row-isolated deployment, customer organizations share MCP infrastructure but keep their data separate. A managed authorization server such as Auth0 or WorkOS supplies per-tenant client registrations. Resource Indicators must limit each token's audience to the resource server for that tenant. This prevents a compromised token from being reused against another tenant's data.

A federated gateway deployment connects multiple backend MCP servers across teams or business units under a central audit requirement. Validate tokens at the gateway and rewrite scopes for each backend. Emit OpenTelemetry spans for tool invocations tied to the originating user identity and LLM call. The Enterprise-Managed Authorization pattern fits this division, with access provisioned centrally and enforced at tool level.

An edge-cached read-only deployment serves high-volume discovery where tools/list responses are stable and safe to cache. Validate OAuth tokens at the gateway edge and tie cache invalidation to scope changes. Tools annotated readOnly and idempotent are candidates for response caching. An AI gateway demonstrates that gateway overhead can remain negligible at high request volume, but caching still has to respect authorization changes.

What a governed, observable authorization layer looks like in a production MCP deployment

A production authorization layer must explain why each tool invocation was allowed. Its audit chain should connect the originating LLM call through an OpenTelemetry span ID to the token validation decision, the scope that allowed the call, and the enterprise user identity. Tool-level cost and usage telemetry then shows which agents use which tools and how often.

Prevention also belongs in the request path. PII blocking, prompt injection defense, and secret detection must run inline before the agent gets the tool responses. Post-hoc logging can record exfiltration, but cannot stop it. Registration events should also surface unrecognized clients in real time, giving security teams visibility that static allowlists alone do not provide.

This is the governance outcome supported by an AI control plane such as Speakeasy, where identity, runtime policy, and centralized telemetry meet. Authorization server selection is the entry point to that system. Get the protocol fit and configuration right, and enterprise AI access can be both narrowly permitted and attributable. Get them wrong, and a polished audit dashboard may still be monitoring the wrong activity.