The Model Context Protocol is about to ship the biggest rewrite of its authorization layer since it launched. Six authorization-hardening SEPs, a stateless protocol core, an Extensions framework, all locked May 21 and publishing July 28, per the Model Context Protocol blog. There is one problem with celebrating it. Almost nobody is running the auth layer it rewrites.

That gap is the actual story. The November 2025 revision already made OAuth 2.1 the mandated model for any HTTP-based MCP server: PKCE, RFC 8707 Resource Indicators, mandatory audience validation, the works. Then an Astrix Security survey cited by Microsoft's App Service team found that only 8.5% of MCP servers use OAuth. The rest lean on static API keys, personal access tokens, or nothing. Microsoft's own writeup puts 25% of public servers at no authentication and 53% on long-lived static keys. So the community is shipping its second major auth revision to an ecosystem where nine in ten servers never adopted the first.

This is not the tool-poisoning problem I've written about before, and it is not the stdio RCE baked into the SDKs. This is the transport-level question underneath both: who is even allowed to call your MCP server, and whether the token they hand you was ever meant for you. It is the least glamorous corner of MCP security. Right now it is also the most neglected.

The spec nobody's running

Read the 2025-11-25 authorization spec and the requirements are not subtle. OAuth 2.1 with PKCE using S256. Clients MUST refuse to proceed if the authorization server does not advertise code_challenge_methods_supported. Servers act as OAuth 2.1 resource servers and MUST validate that a presented token was issued specifically for them as the audience.

Now hold that against 8.5% adoption and 53% on static keys. That is roughly an eleven-to-one gap between what the spec demands and what the field runs. And it is not a gap you close by reading more spec. A server that authenticates with a shared API key cannot do audience binding at all, because there is no audience to bind. The token is a bearer secret, full stop. Whoever holds it is trusted.

I keep coming back to the 25% figure, the servers with no authentication whatsoever. In any other part of infrastructure that number would be a scandal. Here it barely registers, because MCP servers still feel like dev toys to the people standing them up, right up until one of them is wired to a production GitHub org.

Why audience binding is the whole game

MCP servers occupy the worst possible seat for a confused-deputy attack. They hold credentials to real backends (GitHub, databases, cloud APIs) and they take instructions from an LLM that will faithfully relay whatever a web page, an email, or an upstream agent tells it to. The model does not know it is being manipulated. The server does not know the model was.

The spec draws the line exactly where it should. A presented token MUST have been issued for this server as its audience, and the server MUST NOT pass a client's token through to an upstream API. Skip the first check and any valid token from a neighboring service becomes a skeleton key: a token minted for service A sails into your server, which never asks who it was for, and now A's caller is acting as you. This is the same class of blast-radius problem that pushed teams toward per-workload identity with SPIFFE and OAuth instead of one shared key, and it is why static-key MCP servers are structurally unfixable without moving to OAuth first.

Here is the honest boundary, though, and the spec is refreshingly clear about it. The no-passthrough rule and audience validation stop token reuse across services. They do not stop a compromised server from acting on a request that was legitimately scoped to it. Audience binding is containment, not prevention. It turns a stolen neighbor-service token from a skeleton key into a 401. It does not make your server safe to point at prompt-injected input. Anyone selling it as the latter is overselling.

What the July 28 SEPs actually change

The July 28 hardening is real work by capable people, and it is refinement on a foundation most servers have not poured yet.

SEP-2468 requires validating the iss parameter per RFC 9207 to close authorization-server mix-up attacks. SEP-2352 binds credentials to the issuing authorization server, so migrating servers forces re-registration rather than silently trusting a new issuer. SEP-2350 and SEP-2351 clarify scope accumulation and discovery. Every one of these assumes you already speak OAuth. For the 53% on static keys, they are irrelevant until the far bigger jump happens first.

The release candidate also breaks things, and this is where the calendar gets sharp. A stateless protocol core. A 12-month deprecation window for what it replaces. Tier 1 SDKs expected to ship support inside a 10-week validation window. If you pin an SDK to the RC without reading the migration notes, credential re-binding on migration and the stateless core will surprise you at the worst time. This is a version-pinning decision, and it deserves to be made on purpose, the same discipline that keeps a Cosign or supply-chain toolchain from breaking on a point release.

The resource parameter almost everyone omits

If you read one line of the spec, make it this one. MCP clients MUST send the RFC 8707 resource parameter, the canonical server URI (for example resource=https%3A%2F%2Fmcp.example.com), in both authorization and token requests, regardless of whether the authorization server supports it. That single parameter is what lets a server verify a token's audience later. It is also the exact line most homegrown clients leave out, because everything appears to work fine without it. It appears to work because nothing is checking. The day a server starts enforcing audience, the clients that never sent resource break, and the clients that did keep working. Cheap insurance, skipped for no reason but inattention.

The enterprise trap: ID-JAG without audience checks

The part enterprises actually want is the centralized model. Per InfoQ, MCP is adding enterprise-managed authorization built on the Identity Assertion JWT Authorization Grant (ID-JAG), letting an organization broker one login across every connected MCP server instead of each server minting its own trust. One identity plane, real revocation, audit in one place. That is the pattern security teams have been asking for.

It also collapses the instant a downstream server skips audience validation. A centrally issued assertion is precisely the kind of token that gets replayed across resources that never check whom it was for. Roll out ID-JAG across servers where some fraction still do not validate audience, and you have not built single sign-on. You have built single-point-of-token-replay with a nicer dashboard. The centralized model raises the value of the check at the exact moment most servers are not doing it.

Client ID Metadata Documents and the SSRF they invite

The RC changes how strangers establish trust, too. For clients and servers with no prior relationship, the new default is a Client ID Metadata Document: an HTTPS-URL client_id that points to a JSON metadata document, with Dynamic Client Registration demoted to backwards-compatibility. It kills a lot of fragile registration dances.

To its credit, the spec names the new risk instead of hiding it. An authorization server that fetches those client_id URLs is now making outbound requests to attacker-influenced addresses, which is a textbook SSRF surface. CIMDs also cannot, on their own, prevent localhost redirect impersonation. So the mechanism that simplifies trust bootstrapping hands the authorization server a fetch it has to sandbox. If you operate one, treat CIMD URL fetching like any other server-side request to untrusted input: allowlist, block internal ranges, cap redirects.

What to check before July 28

Work these in order. Each ties to a specific number or SEP above.

  1. Find out if you are even in the 8.5%. If your server authenticates with a shared API key or a PAT, the July 28 SEPs do not apply to you yet. Your first move is OAuth 2.1, not SEP-2468. Treat 8.5% as your baseline honesty check, and treat the 25%-no-auth figure as the deadline you have already missed.
  2. Make audience validation a hard gate today. Confirm your server rejects any token whose audience claim is not its own canonical URI, and confirm it never forwards a client token upstream (it should obtain its own token as an OAuth client). This is the one control that turns a stolen neighbor-service token into a 401 instead of a breach.
  3. Add the resource parameter to every client now. It is required by the 2025-11-25 spec, it costs one line, and it is the prerequisite for audience binding to mean anything. Servers that do not enforce it yet will ignore it. Servers that do will start protecting you the moment they flip enforcement on.
  4. Decide your SDK pin deliberately. With a 10-week Tier 1 window and breaking changes (stateless core, credential re-binding on migration), choose whether you adopt inside the window or wait for the July 28 final. If you run a proxy server with static client IDs, budget for the per-client consent the spec now demands, or you reopen the confused-deputy path you just closed.
  5. If you are rolling out ID-JAG, gate it on downstream audience checks. Do not enable centralized authorization until every server behind it validates audience. Ship them together, or the assertion becomes a replayable master key. Static-key servers that route OIDC or brokered tokens should move to short-lived, workload-scoped credentials before they see a single ID-JAG token.

The July 28 rewrite is good work. It is also aimed at a version of the ecosystem that mostly does not exist yet. Fix the foundation the 8.5% number exposes, and the new SEPs become the upgrade they were meant to be. Skip it, and you are hardening a door on a house with no walls.

Sources