# MCP 2026-07-28: what changes for authorization - Published: 2026-07-24 - Tag: SPEC - URL: https://authplane.ai/blog/mcp-2026-07-28-authorization/ - Excerpt: What the MCP 2026-07-28 specification changes for authorization: the stateless core, OAuth-aligned SEPs, the deprecation policy, and what to check before the July 28 final. --- *The next MCP specification finalizes on July 28. Here is what moves on the authorization side, and what to check before it lands.* ## TL;DR - The 2026-07-28 specification is the largest MCP revision since launch. The release candidate locked on May 21, 2026, and the final publishes on July 28, 2026. - The headline change is a stateless protocol core. On the authorization side, a set of SEPs aligns MCP more closely with how OAuth 2.0 and OpenID Connect are actually deployed. - A formal deprecation policy guarantees a minimum twelve-month window, so nothing breaks on July 29. - The current finalized version is still 2025-11-25. If you cite a version anywhere, that is the one to cite until the 28th. If you run an MCP server, the practical question about the 2026-07-28 spec is short: do you have to do anything before it lands? For most teams the honest answer is "not urgently," and this piece explains why. It also covers what is actually changing on the authorization side, since that is the part that tends to get lost under the louder headline about the stateless core. ## What is shipping, and when Per the [Model Context Protocol release-candidate announcement](https://blog.modelcontextprotocol.io/posts/2026-07-28-release-candidate/), the release candidate locked on May 21, 2026, and the final specification publishes on July 28, 2026. The roughly ten-week gap is a validation window for SDK maintainers and client implementers to test against real workloads before the final. One detail trips up a lot of the coverage, so it is worth getting right. MCP versions are date-stamped to mark the last date backwards-incompatible changes were made. "2026-07-28" is a version label, not the day a blog post went up, and not a deadline you personally have to hit. Until the 28th, the current finalized version remains 2025-11-25, which is the version to reference in your own docs and compliance statements in the meantime. ## What changes on the authorization side The release candidate groups the authorization work into six Specification Enhancement Proposals (SEPs). The through-line is consolidation toward how OAuth 2.0 and OpenID Connect are already deployed: fewer MCP-specific quirks, more of the patterns a security team already recognizes from standard OAuth. Notably, most of the six place their requirements on the client or the MCP server rather than the authorization server. {% table %} - SEP - What it changes - Primarily affects --- - SEP-2468 - The authorization server should include an issuer (`iss`) parameter in its authorization responses, including errors, per RFC 9207, and advertise support in its metadata. - Authorization server --- - SEP-837 - Clients declare `application_type` (native or web) during Dynamic Client Registration, so an authorization server does not wrongly reject a CLI's localhost redirect. - Client and AS behavior --- - SEP-2352 - Clients key their stored credentials by issuer and re-register if the authorization server changes. - Client --- - SEP-2207 - Clients may request `offline_access` for refresh tokens, while the authorization server keeps full discretion over whether to issue them. - Client --- - SEP-2350 - Scope accumulation across step-up authorization is a client responsibility, and MCP servers should challenge with the specific scopes an operation needs rather than the union of all scopes. - Client and MCP server --- - SEP-2351 - Confirms MCP uses the standard `oauth-authorization-server` discovery suffix (RFC 8414) and defines no MCP-specific one. - AS discovery {% /table %} The pattern is worth stating plainly, because it is the reassuring part: only one of the six, SEP-2468, adds a new requirement on the authorization server itself, and it is a SHOULD, with the spec signaling a future revision will raise it to a MUST. The rest are client-side, MCP-server-side, or confirmations of behavior that a standards-based authorization server already follows. ## What this means if you have a server in production The headline change, the stateless core, is the one with practical consequences. If your server quietly relies on session state held between calls, that dependency is now the thing to find and remove before you adopt the new transport behavior. This is worth doing regardless of the authorization changes. On timing, the panic framing that some of the coverage is selling is not warranted. The new lifecycle policy guarantees a minimum twelve-month window between a feature being deprecated and removed. Nothing that works on July 28 stops working on July 29. You have a real transition period, and the calm reading of this release is the accurate one. ## Where AuthPlane stands We build directly against the MCP authorization spec, so here is our honest status against the six proposals, written before the final ships. Five of the six place their requirements on the client or the MCP server, or confirm behavior AuthPlane already implements, including the discovery suffix (SEP-2351) and refresh-token issuance (SEP-2207). The one net-new requirement that lands on the authorization server itself is SEP-2468, issuer identification in authorization responses. It is currently a SHOULD, and the spec signals a future revision will make it a MUST. We are implementing it ahead of that change. It is a small, well-scoped addition rather than a structural one. We are not claiming day-one conformance to a spec that has not finalized, and we would rather name the one open item than imply there are none. *We will update this page on July 28 when the final publishes, and again as the issuer-identification change lands. A dated page that visibly maintains itself is more useful, and more trustworthy, than one that quietly goes stale.* ## The bottom line The 2026-07-28 spec is a big release, but for authorization it is a consolidation toward standard OAuth rather than a rewrite of what you know. Find any hidden session state now, note the twelve-month deprecation window, and keep citing 2025-11-25 until the 28th. If you want an authorization server that tracks these revisions so you do not have to, that is what we are building: [github.com/AuthPlane](https://github.com/AuthPlane). ## Sources - Model Context Protocol, The 2026-07-28 Specification Release Candidate. - MCP Authorization specification, 2025-11-25 (current finalized version). - Akamai, The New MCP Specification: What Security Teams Must Prepare For.