MCP 2026-07-28 Is an Auth Migration, Not a Version Bump

By Greg Nowak. Last updated 2026-08-29.

MCP 2026-07-28 looks like a routine protocol release. For anyone already running MCP clients or servers, it is a more substantial change. Protocol-level sessions are gone, requests identify themselves differently, and several OAuth assumptions are now stricter. That reaches into application architecture, authorization-server configuration, gateways, SDK compatibility and security testing.

There is a clear operational upside. MCP’s core is now stateless, so requests can reach any server instance without relying on a shared protocol session. Standard HTTP infrastructure, round-robin load balancing and horizontal scaling become easier to use. But accepting the new protocol version is only the first test. The real question is whether every independent request still carries the correct identity, resource and permissions.

Removing the session exposes hidden dependencies

The 2026-07-28 specification announcement removes the initialization exchange and the Mcp-Session-Id header. Each request now includes its protocol version, client identity and capabilities. Clients may call server/discover before connecting, although discovery is optional.

This is where existing implementations need a careful review. Some servers will have used the old session identifier to choose a tenant, recover application state, associate a user with a tool call or hold a multi-step workflow together. Those requirements have not disappeared. They simply need to be represented explicitly instead of being inferred from a transport session.

A useful test is to route consecutive requests to different server instances. The result should remain correct without session affinity. Authorization decisions should be rebuilt from validated request and token data, not from identity cached against a header that no longer exists. If a workflow needs continuity, the specification recommends returning an application-level handle from the tool and supplying it again with the next call.

OAuth is where most of the migration risk sits

The release tightens authorization in three connected places. An authorization server should return its issuer identifier, and the client must validate that issuer before redeeming an authorization code. This is designed to close authorization-server mix-up paths. Client credentials are also bound to the issuer that created them, which means they cannot safely be reused across authorization servers. Finally, Dynamic Client Registration is deprecated in favour of Client ID Metadata Documents. DCR remains available for backward compatibility until a future specification removes it.

These changes require more than a configuration checkbox. Teams need to know which client talks to which authorization server, how credentials are stored and selected, where redirects lead, and whether the issuer seen during authorization matches the issuer used during code redemption. A flow that completes despite an issuer mismatch may appear functional, but it has failed the security requirement.

Resource binding needs the same scrutiny. RFC 8707 allows a client to identify the target resource when requesting a token. The authorization server can restrict the token’s intended audience to that resource and downscope permissions to what the resource needs. This reduces the risk of a bearer token being accepted by the wrong API.

The practical MCP test is simple: a token issued for server A must fail at server B, even if both servers trust the same identity provider. A connector should never forward a token to another service merely because its syntax looks valid. The component consuming the token needs to validate its issuer, audience, expiry, resource and scope.

Plan the DCR exit without forcing a rushed cutover

DCR still works, so teams can move in a controlled sequence. The specification provides a minimum twelve-month deprecation window. Use that time to find every client that registers dynamically, document its redirect patterns and identify the authorization servers involved. Then determine which clients and servers can move to Client ID Metadata Documents and where temporary compatibility is still required.

For estates with several clients or SDK generations, a period supporting both paths will usually be easier to manage than a single cutover. The release notes state that the TypeScript, Python, Go and C# Tier 1 SDKs support the new version. They also acknowledge the migration cost for implementations that relied on session identifiers. Protocol version, client SDK, server SDK and authorization configuration therefore need to be tested as a complete combination.

Enterprise-managed authorization now has operational consequences

MCP’s Enterprise-Managed Authorization extension places access policy in an organization’s identity provider. It supports central policy, corporate SSO and centralized revocation. In the documented flow, the MCP client exchanges an identity assertion grant with the MCP server’s authorization server. That server must validate the assertion’s signature, issuer, audience and expiration before mapping identity-provider claims to permissions.

This creates a useful governance model, along with another trust boundary that needs an owner. Claim mapping should use a stable subject identifier and clear rules for scopes and resources. Revocation needs a real test. Because the extension is opt-in and client support varies, rollout plans also need capability checks and defined fallback behaviour.

This is already appearing in production products. Anthropic’s enterprise-managed connector authorization is generally available for Claude Team and Enterprise plans. Administrators can grant connector access by role, narrow the requested permissions, pilot access with a custom role and revoke it through the identity provider.

There is an important lifecycle detail in the product documentation: existing sessions end when the connector’s access token expires or is revoked. Changing an administrative setting does not necessarily make every active token disappear immediately. A proper revocation test must account for the token’s lifetime and record how long access remains available.

A migration sequence that produces useful evidence

Start with an estate map covering clients, servers, SDK versions, transports, authorization servers, redirect URIs, registration methods, credential stores and target resources. Add the business owner and intended users for every connector. An integration with no clear owner should not drift into the new authorization model unnoticed.

Build a compatibility environment that deliberately spreads requests across server instances. Test discovery, tool listing, tool calls and multi-step flows without protocol-session affinity. Record any application state that needs an explicit handle, and confirm that identity is evaluated afresh for each request.

Next, tighten token handling. Validate the issuer before exchanging a code, keep credentials separate by issuer, request tokens for the intended resource and reject an incorrect audience. Include expired tokens, malformed claims, excessive scopes and tokens replayed against another server. These negative tests reveal far more than one successful sign-in.

For enterprise-managed access, begin with a narrow role and least-privilege scopes. Check onboarding, denial for an unapproved role, claim mapping, deprovisioning and the actual delay before access ends. Expand the pilot only when the logs and administrative records can explain who received access, under which policy and for which resource.

Use the release as an architectural checkpoint

The new MCP roadmap keeps agent identity and enterprise-ready security among its active priorities. The direction includes proof-of-possession, workload identity federation, delegated authority and standardized token exchange, moving away from pasted API keys and long-lived bearer tokens.

A package upgrade may get an MCP server running while leaving issuer selection ambiguous, credentials reusable or tokens too broad. An authorization migration goes further: it produces a reliable inventory, explicit trust boundaries and repeatable evidence that invalid access is rejected.

This work benefits from one person owning the joins between infrastructure, identity configuration, SDK compatibility and testing. Greg can help map the estate, run the stateless and authorization tests, remove unsafe token reuse, and turn a limited enterprise-access pilot into a migration plan the wider team can operate.

Related on GrN.dk

• Google’s August 18, 2026 Content API Cutoff: Feed Cleanup Before Merchant API Migration
• Apache 2.4.68 Is a Reminder That Old Proxy Rules Need a Real Audit
• Background AI Tasks Need Queues—not Just Longer API Calls

Need help with this kind of work?

Plan your MCP authorization migration Get in touch with Greg.

Sources

• The 2026-07-28 MCP Specification
• Enterprise-Managed Authorization
• The New MCP Roadmap
• RFC 8707: Resource Indicators for OAuth 2.0
• Authorize MCP Connectors for Your Entire Organization