MCP's 2026-07-28 spec hardens OAuth and adds enterprise-managed authorization
RFC 9207 issuer validation is now mandatory, dynamic client registration is deprecated in favour of client ID metadata documents, and an enterprise extension lets admins govern agent access through Entra ID or Okta instead of per-server consent clicks.
The Model Context Protocol's 2026-07-28 specification is the largest revision since the protocol shipped, and most of it is identity work. Authorization hardening is mandatory now: authorization servers must return the iss parameter and clients must validate it per RFC 9207, closing an authorization-server mix-up hole. Clients declare application_type at registration so desktop and CLI localhost redirects are handled correctly, and client credentials are bound to their issuing authorization server so they cannot be replayed against another. Dynamic Client Registration is formally deprecated in favour of Client ID Metadata Documents, with a year of backward compatibility. The Enterprise-Managed Authorization extension ships alongside, letting an administrator govern which MCP servers staff may reach through an existing identity provider.
Why it matters
The first year of MCP repeated OAuth's early mistakes at speed: dynamic registration open to anyone, per-server consent screens trained on users who click approve, and no way for an enterprise to see or revoke any of it. This release fixes the protocol-level parts of that, and the iss requirement in particular is the fix for a class of mix-up attack that took the OAuth ecosystem years to close the first time.
Enterprise-managed authorization matters more to identity teams than the stateless core does. It moves agent tool access into the identity provider you already govern, which means agents can enter the same access reviews as staff. C1 shipped support ahead of the spec freeze.
The gap is your own servers. Internal MCP servers built last quarter implement none of this, and they are the ones with the broad tokens. Inventory before you trust the extension.
Source: Model Context Protocol
Related on Start with Identity
- BlogGoogle and Mastercard's answer to "can I trust an AI agent to pay for this" is a cryptographic mandate
Google's Agent Payments Protocol and Mastercard's Verifiable Intent framework, both contributed to the FIDO Alliance for standardization, define how an AI agent
- BlogA loose PHP comparison let attackers sign in as WordPress admin through SAML
Two unauthenticated bypasses in the miniOrange SAML 2.0 Single Sign On plugin, CVE-2026-61979 and CVE-2026-15981, treat OpenSSL's error return as a valid signat
- BlogAnthropic's own Claude escaped a security test, stole a vendor's credentials, and used them
During evaluations Anthropic believed were sandboxed, Claude models broke out of test environments and hit real infrastructure at three organizations, in one ca
- RecipeImplement OAuth authorization code flow with PKCE
A step-by-step, framework-agnostic implementation of the OAuth 2.0/2.1 authorization code flow with PKCE: generating the verifier and challenge, building the au
- GuideAuthentication vs Authorization: The Difference That Trips Everyone Up
Authentication and authorization sound alike and are often shortened to the same "authZ/authN," but they answer different questions. Getting them straight is fo
- GlossaryAuthorization Code Flow
The recommended OAuth 2.0 flow for apps with a user: the app receives a short-lived code, then exchanges it for tokens from a back channel. Combined with PKCE f