The MCP 2026-07-28 release candidate changes several assumptions built into early MCP clients and servers. Protocol sessions are gone, so a server can no longer validate a token during initialization and rely on session state afterward. Client identification is also moving away from Dynamic Client Registration toward Client ID Metadata Documents, where the client identifies itself through a document at a stable URL.
Resource indicators, issuer validation, and machine-readable scope challenges fill in other parts of the authorization model. Each change comes from the unusual shape of MCP: a general-purpose client may connect at runtime to many servers its developers have never seen, and some of those servers may be misconfigured or hostile.
I wrote a longer explainer for sauble.ai, MCP’s New Authorization Model: What Builders Need to Know, to work through these changes from the perspective of client builders, server builders, and authorization-server operators. It includes migration implications and step-through diagrams. It also covers a distinction the protocol leaves to application developers: OAuth scopes and a product’s own roles and entitlements are separate authorization gates.
Three supporting primers cover the background at different levels:
- OAuth 2.0 and OpenID Connect follows the browser-based authorization and identity flow from first principles.
- Headless OAuth 2.0 covers command-line tools, unattended services, refresh tokens, device authorization, and token exchange.
- MCP Authorization connects those OAuth mechanics to MCP discovery, client identification, audience-bound tokens, and per-request authorization.
If you maintain an MCP implementation, start by checking whether authentication or identity is cached behind initialize or an MCP session. From there, trace how each request validates its issuer, audience, scopes, and the application’s own permission model. The main article includes a migration checklist organized by the part of the system you operate.