Read the changelog for the 2026-07-28 Model Context Protocol spec and you can sort the authorization work into a pile of six SEPs. Then notice what is not in the pile: no new grant type, no MCP-specific token format, no bespoke handshake. Every one of the six makes MCP behave more like a plain OAuth 2.0 / OpenID Connect deployment — the kind your identity team already runs.

That is the whole story, and it is easy to miss. The stateless changes in the same release got the headlines because deleting the session is dramatic. The auth changes are quieter and, for anyone shipping an MCP server into an enterprise, more consequential. The spec's own framing is blunt: six SEPs "harden the authorization specification to align more closely with how OAuth 2.0 and OpenID Connect are deployed in practice."

The auth rewrite adds nothing MCP-specific. It is a capitulation to how identity actually works — and that is the point.

The one that is load-bearing#

If you change exactly one thing before July 28, change this: SEP-2468 makes clients MUST-validate the iss (issuer) parameter on every authorization response, per RFC 9207.

The attack it closes is the mix-up attack, and it only exists once a client talks to more than one authorization server — which is exactly the world MCP is heading into, where one agent holds credentials for a dozen tool servers behind different identity providers. Without issuer identification, an attacker who controls one authorization server can trick the client into sending an authorization code, or a token, to the wrong server. Validating iss forces the client to check who actually answered before it trusts the response.

The forward-looking clause is the part to internalize now: the spec says that in a future version, clients will be expected to reject any authorization response that omits iss. So if you run an authorization server and you are not returning iss today, you are on a clock. Start emitting it before rejection becomes mandatory, not after your clients start failing.

The other five, and what they reveal#

The remaining SEPs are less dramatic individually, but read together they sketch the same thesis — MCP is sanding down the places where its earlier auth text disagreed with real IdP behavior.

What it means for your build#

The upshot is asymmetric. Servers get off easy: if you already expose Protected Resource Metadata and validate token audience — the model since 2025-06-18 — you are close to compliant, because the resource-server contract did not change. The Resource Indicators audience-binding you should already be doing still stands, and the confused-deputy risks it defends against have not gone anywhere.

Clients carry the load. Validate iss. Handle issuer-bound re-registration. Send application_type if you touch OIDC providers. None of it is hard; all of it is the difference between an agent that authenticates cleanly against Entra or Okta and one that fails in ways your security team will not sign off on.

The tell, across all six, is that MCP stopped trying to be interesting about identity. Auth is the one layer where "novel" is a synonym for "unaudited," and the 2026-07-28 revision reads like a protocol that finally accepted it. The most secure thing a tool protocol can do about login is to be aggressively unoriginal — and, for once, that is the design goal.