Reading the 2025-11-25 MCP authorization specification: what buyers should check

Published 2026-07-28 · NextGen Identity Security desk · 4 min read

The Model Context Protocol publishes dated versions of its specification. Our MCP security page was scored against the authorization text dated 2025-06-18; a newer version dated 2025-11-25 is also published. This post sets out what the newer text states and turns each point into something to check in a gateway or MCP server.

What stays the same

• Authorization is optional. HTTP-based transports should conform to it; STDIO transports should not, and should take credentials from the environment.
• The MCP server is an OAuth 2.1 resource server and must publish Protected Resource Metadata (RFC 9728).
• Clients must send a resource parameter (RFC 8707) naming the MCP server.
• Servers must validate that each token was issued for them and must not pass tokens through to other services.
• Authorization servers should issue short-lived access tokens.

Points the 2025-11-25 text states explicitly

• Clients must implement PKCE with the S256 method.
• Client ID Metadata Documents should be supported; Dynamic Client Registration may be supported, for backwards compatibility.
• Public clients must rotate refresh tokens.
• A request without a valid token gets a 401 response whose WWW-Authenticate header points to the resource metadata.
• When a token lacks a needed scope, the server responds 403 with insufficient_scope, so the client can step up and ask for more.

What to check in a gateway or MCP server

1. Ask which version of the authorization text the gateway and your MCP servers follow, and how they handle clients built to the older one.
2. Send a request with no token and confirm a 401 that points to the resource metadata.
3. Send a token that lacks a needed scope and confirm a 403 insufficient_scope response rather than a silent failure.
4. Confirm that PKCE uses S256.
5. For public clients, confirm that refresh tokens rotate on use.
6. Confirm that the gateway never forwards a client's token upstream.

Why step-up matters for agents

The step-up behavior fits the specification's security advice on scope minimization: start with the smallest set of scopes and ask for more only when a privileged operation is attempted. For AI agents, which choose their own next step, this avoids granting a broad scope on day one just in case. It pairs with per-call authorization, where a gateway checks each tool call against policy.

Where a gateway helps

Most of these rules are obligations on each MCP server and client. A gateway can enforce several of them once, for every server behind it: rejecting tokens issued for other audiences, obtaining separate upstream tokens instead of passing tokens through, and recording each decision. That is the main argument for putting one in front of third-party MCP servers, and it is why the MCP security page scores gateways on credentials, per-call policy and audit rather than on protocol features alone.

Why version dates matter in procurement

Specifications change, and products follow at different speeds. Writing the version into a request for proposal, for example asking a vendor to state conformance with the 2025-06-18 or the 2025-11-25 authorization text, turns a general claim of MCP support into something that can be checked and held to.

Will our scores change?

Not on this reading alone. Our MCP criteria measure what gateways publish about credentials, per-call policy, identity binding, audit, server isolation and deployment, and those do not depend on the specification version. If a vendor publishes which version it supports, we will note it on the MCP security page with the date.