MCP authorization rewrite — JWT audience, issuer and scope checks — What does it mean?
The news. By November 8, 2026, the MCP project had merged a rewrite of its authorization guide for the 2026-07-28 specification and the draft copy. The updated TypeScript, Python and C# samples use v2 SDKs and validate JWT audience, issuer and scope, and the guide lists common server mistakes. The pull request changed 2 files, with 1,082 additions and 1,848 deletions. Read the pull request →
Think of the MCP server as one gate at a festival. A signature check only proves the ticket office printed the wristband. It does not prove the wristband opens this gate. The guide's samples therefore ask three more questions, and each one maps to a printed field.
Audience: is this wristband for my venue? The guide says to compare the audience exactly with the server's URL, or with an identifier the authorization server uses for this server only, and not to accept a value several servers share, such as api. The client's resource value should become the token's aud claim. Issuer: did my one trusted ticket office stamp it? Accept a single issuer and reject tokens from other issuers or tenants. Scope: does it open this zone? If the token is valid but lacks a scope, the server answers 403 with an insufficient_scope challenge, and the client starts a step-up flow that requests the new scopes together with the old ones.
In short, the gate checks the venue, the ticket office and the zone before letting anyone in. In the TypeScript sample these checks are arguments to one library call: jwtVerify receives the expected issuer, the expected audience, requiredClaims: ["exp"] and a clockTolerance of 30. The guide's advice is to lean on such libraries: don't write your own token validation.
Two neighbouring rules close gaps the three checks leave open. Accept only access tokens, never an ID token. And when the server cannot reach the JWKS or introspection endpoint, return a 5xx, not a 401, because a 401 makes users log in again and that does not fix an outage. For how a wrong audience becomes an attack, see Tools as Attack Surface; for where these tokens come from, see MCP, Two Ways.
Two MCP servers, files.example.com/mcp and mail.example.com/mcp, share one authorization server (illustrative). A client gets a token with aud set to the files server. The files server compares audience and issuer: match, accept. The mail server compares the same token: audience differs, reject. Now suppose both servers were configured to accept a shared audience such as api: the same token would open 2 of 2 gates instead of 1 of 2, even though the user consented to one. Exact audience comparison is what keeps the count at 1.
Goes deeper in: AI Agents → Tool Use & Function Calling → Tools as Attack Surface
Related explainers
- MCP authorization rewrite — Client ID Metadata Documents — the client-side half: how a client gets its ID before any token exists
- MCP SEP-2468 — the iss parameter — a different issuer check, on the client side