MCP OAuth (2026): How Authorization Works, and Who Gets It Right

What is MCP OAuth? MCP OAuth is the authorization layer of the Model Context Protocol. When an AI client such as Claude, Cursor or a custom agent connects to a remote MCP server, the server answers with a 401 and points to its metadata, the client finds the authorization server, the user signs in and consents, and the client receives an access token that works for that one MCP server only. The current spec (revision 2026-07-28) builds this on OAuth 2.1, PKCE and three RFCs: 9728 (Protected Resource Metadata), 8707 (Resource Indicators) and 9207 (issuer identification).

Our finding: we probed 74 official remote MCP servers on November 6, 2026. The basics are done almost everywhere. The newer parts of the spec are not: only nine servers pass all six of our readiness checks.

MCP authorization moved fast, and the spec keeps tightening it. The 2026-07-28 revision deprecated Dynamic Client Registration, prefers Client ID Metadata Documents, and tells clients to check the issuer of every authorization response. Vendors shipped remote servers through all of those changes, so the question for anyone building or buying is simple: which servers follow the current rules?

To answer it, we sent one anonymous request to each of 74 official remote MCP endpoints and read their public discovery documents. This guide explains how MCP OAuth works, what we found, where implementations fail (with the CVEs to prove it), and two checklists: one for server builders and one for security teams. For MCP security beyond authorization, such as prompt injection, tool poisoning and the OWASP MCP Top 10, see our MCP security guide.

Key findings (probe of 74 official remote MCP servers, November 6, 2026)

• OAuth is the norm: 68 of 74 servers publish OAuth discovery, and 63 refuse to list tools until the client presents a token. The other six are open, no-login servers.
• The basics are solid: all 68 OAuth servers advertise PKCE S256, and 66 (97%) publish RFC 9728 Protected Resource Metadata.
• The newer parts lag: only 28 (41%) advertise Client ID Metadata Documents and 24 (35%) advertise the RFC 9207 iss parameter.
• Deprecated registration lives on: 59 (87%) still offer Dynamic Client Registration, which the spec now keeps only for backwards compatibility.
• Nine pass all six checks: Apify, Clerk, Context7, Fireflies, Linear, Notion, Railway, Sentry and Tavily.
• Real bugs follow the gaps: seven CVEs in our research map to the same weak points, from clients trusting server-supplied metadata to servers that skip audience checks.

How MCP authorization works

MCP authorization applies to remote servers reached over HTTP. The spec defines three roles: the MCP client (the AI app or agent), the MCP server (the protected resource that exposes tools) and the authorization server (which signs the user in and issues tokens).

The flow, step by step:

1. First contact. The client calls the server, for example tools/list, without a token.
2. The 401. The server replies 401 Unauthorized with a WWW-Authenticate header that points to its Protected Resource Metadata.
3. Protected Resource Metadata (RFC 9728). The client fetches a small JSON document that names the resource (the server’s own URL) and the authorization servers it trusts. MCP servers MUST implement it (MCP spec; RFC 9728, April 2025).
4. Authorization server metadata. The client reads what the authorization server supports: PKCE methods, client registration options and whether it sends iss.
5. Client registration. The client identifies itself, in the spec’s order of preference (more below).
6. Authorization request. The user signs in and consents in the browser. The request carries a PKCE S256 challenge and a resource parameter naming the MCP server.
7. Token request. The client exchanges the code, sending the PKCE verifier and the same resource value.
8. Tool calls. The client sends the token as a bearer token. The server checks that the token was issued for it, and never passes it on.

The building blocks

OAuth 2.1. Authorization servers MUST implement OAuth 2.1 (MCP spec). OAuth 2.1 is still an IETF draft: the MCP spec cites draft -13, while the working group published draft -17 on October 30, 2026 (IETF).

PKCE S256. Clients MUST use PKCE with the S256 method, and MUST refuse to continue if the authorization server’s metadata does not list supported challenge methods (MCP spec, security considerations).

Resource Indicators (RFC 8707). The resource parameter MUST appear in both the authorization request and the token request, and servers MUST validate that a token’s audience is themselves (MCP spec; RFC 8707, February 2020). This is what makes an MCP token useless anywhere else.

Issuer identification (RFC 9207). Clients MUST record which authorization server they expect and apply the iss validation in RFC 9207 section 2.4. If the server advertises iss support but a response arrives without it, the client rejects it (MCP spec; RFC 9207, March 2022). On the server side, including iss is currently a SHOULD, expected to become a MUST. Client credentials are also keyed to the issuer (MCP spec, client registration).

Client registration: CIMD replaces DCR

An authorization server has to know which client is asking. The spec now gives clients an order to follow (MCP spec, client registration):

1. Pre-registered credentials, when the client and server already have a relationship.
2. Client ID Metadata Documents (CIMD), where the client_id is an HTTPS URL that hosts the client’s metadata. The authorization server fetches it, so nothing has to be registered in advance. CIMD is an IETF draft, now at -03 (November 2, 2026), while the spec cites -00 (IETF).
3. Dynamic Client Registration (DCR) as a fallback. DCR is deprecated and kept for backwards compatibility.
4. Ask the user for client details if nothing else works.

DCR lets any client register itself, so authorization servers collect registrations from anyone, with little tying a client name to a real publisher. CIMD keeps the no-setup convenience but anchors identity to a URL the publisher controls.

The spec also defines stable authorization extensions in 2026-07-28 versions: Enterprise-Managed Authorization and OAuth Client Credentials (MCP ext-auth). Both sit outside the core flow we tested.

What this means: an MCP token should be good for one server, from one issuer, for one client, obtained with PKCE. Each RFC closes one gap. When a server or client skips one, the gap reopens, and the CVEs later in this guide show what that looks like.

Our probe: how 74 official MCP servers handle OAuth

We probed 74 official remote MCP endpoints run by the vendors themselves. Each received one anonymous request, and we read only public discovery documents. We made no tool calls and used no tokens.

The headline split:

• 68 servers publish OAuth discovery, either RFC 9728 metadata or the older 2025-03-26 layout.
• 63 return a 401 to an anonymous client before listing tools.
• 5 OAuth servers still list tools anonymously: Railway, Hugging Face, Context7, Exa and Google Maps Grounding. Listing tools is not proof that the tools run without a token; these servers may gate calls rather than discovery.
• 6 are open, no-login servers: DeepWiki, Firecrawl, Browserbase, Cloudflare Docs, Microsoft Learn and AWS Knowledge.

The six readiness checks

We scored each OAuth server against six checks drawn from the 2026-07-28 spec. Dynamic Client Registration is reported separately and does not count toward the score, because it is deprecated rather than forbidden.

The oldest parts of MCP OAuth are close to universal. The newest, CIMD and issuer identification, reach well under half of servers. Most servers are not broken; they are a spec revision or two behind.

Who gets it right: the nine that pass all six

Nine servers pass every check: Apify, Clerk, Context7, Fireflies, Linear, Notion, Railway, Sentry and Tavily. Two of them, Context7 and Railway, are also among the five OAuth servers that list tools anonymously, so a perfect discovery score does not mean discovery is gated.

Here is how a selection of widely used servers scored, from our dataset:

All servers in the table advertise PKCE S256. The full 74-row table, with every check, is in the dataset.

Where servers fall short

• Resource mismatches (9 servers). Airtable, Semgrep, Slack, Gamma, MongoDB, Resend, Ahrefs, Cloudinary and Pipedream publish a resource value that does not exactly match the endpoint. Pipedream names a different host entirely. Under a strict reading of RFC 9728 a client should reject this; lenient clients may still connect.
• Trailing-slash issuer mismatches (3 servers). Box, Semgrep and Google Maps Grounding publish an issuer that differs from what is expected only by a trailing slash. Trivial to fix, but a strict client comparing strings will fail.
• Legacy layout (2 servers). Atlassian and Plaid still use the older 2025-03-26 discovery layout instead of RFC 9728 metadata.
• No self-service registration. A few servers, including GitHub, Slack and HubSpot, advertise neither CIMD nor DCR in our data, so a new client has no automatic way to register and depends on pre-registration.

Our results line up with an independent table. X1Y1’s audit of official vendor servers, dated November 4 on x1y1.co and reposted to dev.to (X1Y1, vendor audit), covers 61 servers that require login. Of 183 checks where our datasets overlap, 182 agree. The only difference is PagerDuty, which advertised iss when we probed.

What this means: if you are choosing between MCP servers, the 401, PKCE and metadata are table stakes. CIMD support and iss are the real signals of a team that tracks the spec. If you run a server, those two are also the quickest gains: they are mostly authorization server settings, not rewrites.

Common MCP OAuth failures, and the CVEs behind them

Our probe only sees what servers advertise. Wider audits and published CVEs show what goes wrong in practice.

The audits. Most are self-published by companies that sell MCP scanning tools, so read them as vendor research:

• mcpprobe (vendor): 11,682 of 20,981 assessable remote servers in the official registry, 55.7%, answered without a login (mcpprobe, November 2, 2026).
• CrawlCheck (vendor): of 1,366 registry servers that ask for authorization, 597 (44%) had at least one finding. The top finding: 244 default to requesting every scope (CrawlCheck, October 9, 2026).
• patchbay (self-published by the CLI’s author): 12 of 25 public servers scanned enforced authentication (patchbay, November 3, 2026).
• Fudan University (academic preprint, not peer reviewed): of 7,973 live remote servers, 40.55% exposed tools without authentication; all 119 OAuth servers tested had at least one flaw, 325 in total, leading to nine CVEs (arXiv 2605.22333, May 2026).
• The Agent Times summarised four of these audits on November 4 (The Agent Times).

The registry-wide numbers are much worse than ours because the registry includes hobby and test servers. Our 74 are official vendor endpoints, which is the set enterprises actually connect to.

The CVEs. Each one maps to a specific rule in the flow above.

*Scores for CVE-2026-123272 and CVE-2026-123271 come from the CNA, VulnCheck (CVSS 4.0: 5.1). NVD published both on November 5, 2026 but has not yet analysed them.

Three lessons stand out. Clients are attack surface too: the two newest CVEs and the most severe one are client-side bugs where a malicious server feeds bad metadata. Audience validation is easy to skip quietly, because everything still works without it. And a valid token is not the end of authorization: the session has to belong to the user presenting it.

Token passthrough and the confused deputy

Two failure modes get their own sections in the spec, because they let an MCP server leak access it was never meant to give.

Token passthrough is when an MCP server accepts a token issued for something else and forwards it to an upstream API. It is forbidden outright: MCP servers “MUST NOT accept or transit any other tokens” (MCP spec). Passthrough skips the audience check, bypasses the server’s own scopes, rate limits and logs, and leaves upstream records pointing at the wrong actor. If your server calls another API, it gets its own token for that API.

The confused deputy hits MCP servers that act as proxies to a third-party API using one static client ID. An attacker registers a client (often through DCR), then sends the user a crafted link with the attacker’s redirect URI. Because the user has consented before, the third-party authorization server sees its consent cookie for the static client ID and skips the consent screen. The authorization code ends up with the attacker. The spec’s required mitigations (MCP security best practices):

• Keep a consent registry per client ID and ask again for every new client.
• Match redirect_uri exactly, with no patterns.
• Use a single-use state value with a short expiry (around 10 minutes), set only after the user consents.
• Use __Host- prefixed cookies for consent, bound to the client.

What this means: the high DCR share in our probe matters most here. Open registration plus a proxy with a static upstream client ID is the exact recipe for a confused deputy. If you must keep DCR for older clients, the per-client consent registry is not optional.

MCP OAuth checklist for server builders

1. Serve RFC 9728 Protected Resource Metadata and point to it from the WWW-Authenticate header on every 401.
2. Make resource match your endpoint exactly, same scheme, host and path. Check for trailing slashes in both resource and the issuer.
3. Gate discovery as well as calls, unless you deliberately run an open server. If tools/list is public, make sure every tool call still requires a valid token.
4. Advertise PKCE S256 in authorization server metadata.
5. Support Client ID Metadata Documents and advertise client_id_metadata_document_supported.
6. Send iss in authorization responses and advertise authorization_response_iss_parameter_supported. It is a SHOULD today and expected to become a MUST.
7. Plan your DCR exit. Keep it only as long as older clients need it, and pair it with per-client consent.
8. Validate audience on every request. Reject tokens not issued for your server (see CVE-2026-115413).
9. Never forward the client’s token. Get separate credentials for upstream APIs.
10. Advertise scopes and request the minimum. Give a scope hint in the 401 or scopes_supported, and do not default to every scope.
11. Bind sessions to the authenticated user, not only to a session ID (see CVE-2026-52869).
12. If you proxy a third-party API, implement the confused-deputy controls: per-client consent, exact redirect_uri, one-time state, __Host- cookies.
13. Test with a strict client. Lenient clients hide resource and issuer mismatches that strict ones will reject.

If you are also building MCP clients or agents, treat everything a server sends as untrusted: validate the resource before requesting a token (CVE-2026-123272), sanitise URLs before opening them (CVE-2025-6514), refuse to proceed without S256, and check iss whenever the server advertises it.

Checklist for enterprise buyers and security teams

Most teams do not build MCP servers; they approve the ones employees and agents connect to. Use these questions in vendor reviews, alongside the platform evaluation in our guide to AI agent platforms.

1. Does the server require a token before listing tools? If not, ask whether tool calls are gated, and why discovery is open.
2. Is the token audience-bound? Ask for confirmation that the server validates audience and rejects tokens issued for other resources.
3. Does it pass through tokens? The only acceptable answer is no.
4. Does the authorization server support CIMD and send iss? These are your best quick proxies for spec currency. Only 41% and 35% of official servers do today.
5. What happens to DCR? Ask for a timeline to retire it, and whether consent is tracked per client.
6. What scopes are requested by default? Push for least privilege; one vendor audit found 244 servers that default to every scope.
7. Can you pre-register or restrict clients? For company rollouts, ask about the Enterprise-Managed Authorization extension and whether you can limit which clients connect.
8. How fast are auth bugs fixed? Check the vendor’s advisory history and SDK versions against the CVEs above.
9. Re-check after updates. Servers change. A one-time review goes stale, which is the same drift problem we describe in our shadow AI guide.

Then inventory what is already connected, and build MCP servers into your agent governance; our overview of enterprise AI agents covers the wider rollout questions.

What this means: “supports OAuth” is no longer a meaningful answer in a security review. Ask which revision of the MCP authorization spec the server follows, and verify it yourself: the discovery documents are public, and the checks in our table take minutes.

Methodology

Sample. 74 official remote MCP endpoints run by the vendors themselves, listed in our dataset with their URLs.

Method. On November 6, 2026 we sent one anonymous request to each endpoint and fetched only public discovery documents: the Protected Resource Metadata (or the legacy 2025-03-26 authorization server metadata on the server’s own origin) and the authorization server metadata. We made no tool calls, presented no tokens and attempted no registration. A server counts as “OAuth” if it publishes OAuth discovery, and as “requires a token” if it returned 401 to the anonymous request.

Checks. Six checks, each pass or fail: Protected Resource Metadata (RFC 9728); PKCE S256 advertised; Client ID Metadata Documents advertised; RFC 9207 iss advertised; a scope hint in the 401 header or metadata; and an exact match between the metadata’s resource and the endpoint URL. Dynamic Client Registration is reported but excluded from the score.

Cross-check. We compared our results with X1Y1’s published 61-vendor table. Of 183 overlapping checks, 182 agree; the exception is PagerDuty’s iss, which X1Y1 recorded as absent and we found advertised.

Caveats. This is one snapshot, from one network, using passive anonymous requests. We measured what servers advertise, not how they behave with a token, so a server can advertise a feature and implement it badly. The resource-match check uses the strict RFC 9728 reading; lenient clients may connect to some servers that fail it. Five OAuth servers list tools anonymously, which does not prove their tools run without a token. Spec facts reflect the 2026-07-28 revision and pages read on November 11, 2026. Third-party audits are described as published by their authors; most are vendor research. CVE scores are CVSS 3.1 from the NVD record unless marked otherwise.

Download the dataset (CSV)

MCP OAuth FAQ

Does MCP use OAuth?

Yes, for remote servers. The MCP spec requires authorization servers to implement OAuth 2.1 and MCP servers to publish RFC 9728 Protected Resource Metadata. In our probe, 68 of 74 official remote servers publish OAuth discovery.

What is the difference between CIMD and Dynamic Client Registration?

With Dynamic Client Registration, a client registers itself with the authorization server. With a Client ID Metadata Document, the client ID is an HTTPS URL hosting the client’s metadata, so no registration call is needed. The 2026-07-28 spec prefers CIMD and deprecates DCR.

Why does MCP need RFC 8707 resource indicators?

They bind each token to one MCP server. The client names the server in the resource parameter, and the server rejects any token not issued for it. Without that, a token for one server could be replayed against another.

What is token passthrough in MCP?

An MCP server accepting a token meant for another service and forwarding it upstream. The spec forbids it; servers must use their own credentials for upstream APIs.

Do MCP clients have to check the iss parameter?

Yes. Clients must record the expected issuer and validate iss under RFC 9207, rejecting a response that lacks it when the authorization server advertises support. Servers should send it; only 35% of official servers in our probe advertise it.

Which MCP servers implement OAuth best?

In our November 6, 2026 probe, nine passed all six readiness checks: Apify, Clerk, Context7, Fireflies, Linear, Notion, Railway, Sentry and Tavily. It is a snapshot of advertised features, not a security audit.

This article is information for builders and security teams, not a security certification of any product. Re-check servers before you rely on them.