The Server Picks the Token Endpoint: Issuer Validation in Agent OAuth Clients

Overview

Picture a nightly job that runs an agent against a list of MCP servers. The job authenticates as a machine, not a person, so it carries a client_id and a client_secret that your platform team registered with your company's authorization server. Someone adds a new server URL to the list. It looks like an internal tool. The job connects, gets a 401, and starts OAuth discovery the way the SDK is built to. The new server says it has no protected resource metadata. The SDK falls back to asking the server itself for authorization server metadata. The server answers with a document whose issuer is your real identity provider, and whose token_endpoint is a host it controls. The job posts its client secret to that host. No browser opened. Nobody clicked anything. The secret is now reusable by someone else for as long as it stays valid.

That scenario is the one the advisory scores highest. GHSA-qx49-fqc8-xw99 on the mcp package gives it CVSS 7.5 with the vector AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N, and 6.5 where a user has to take part in the flow. The advisory's summary names two root causes: "the authorization server metadata issuer was not validated on every discovery path," and credentials were not bound to the authorization server they were meant for. Affected versions are 1.9.1 through 1.29.1 and 2.0.0a1 through 2.1.1. The fixes are 1.30.0 and 2.2.0.

The bug is specific. The lesson is not. Every agent that speaks MCP over HTTP runs the same conversation: a server you do not own tells your client where authorization happens. The fixed SDK's own deprecation warning puts the design problem in one sentence. If you leave out the issuer, "the MCP server decides which authorization server receives this client's credentials."

The Discovery Chain

The current MCP specification is dated 2026-07-28. Its authorization section puts the roles plainly. The MCP server is an OAuth 2.1 resource server. The MCP client is an OAuth 2.1 client. The authorization server "may be hosted with the resource server or a separate entity." Everything the client knows about that authorization server, it learns at runtime from documents it fetches.

Read those five steps as a chain of custody. Step 2 is the MCP server's claim about who the authorization server is. Step 3 turns that claim into endpoints, and the issuer check is what stops a document served from one place from speaking for another. Step 5's iss check only means something if step 3 was validated. The spec says so directly: the response validation "provides no protection if the expected issuer was obtained from an unvalidated source." RFC 9207, which defines iss, makes the same point from the other side: clients relying on unvalidated metadata cannot get mix-up protection from it.

The Flaw, Path by Path

Cycode's write-up of the report shows the vulnerable condition in one line of the SDK's OAuth flow. Issuer validation only ran when the client already had an authorization server URL from protected resource metadata:

# vulnerable shape (as published in Cycode's write-up)
if self.context.auth_server_url is not None:
    validate_metadata_issuer(asm, self.context.auth_server_url)

# fixed shape: always compute an expected issuer, always check it
expected = self.context.auth_server_url or self.context.get_authorization_base_url(url)
validate_metadata_issuer(asm, expected)

On the fallback path, auth_server_url is None, so the check never runs. Whatever the server returned became the client's view of the authorization server. The fix computes an expected issuer on every path. With no resource metadata, that expected issuer is the MCP server's own origin, which is exactly what the legacy model said the authorization server would be. The 2.2.0 release notes state the result: "Authorization server metadata whose issuer isn't the server's own origin is now rejected with OAuthFlowError."

Here is the forged document for Path A, reduced to the fields that matter. The client fetched it from https://tools.attacker.example/.well-known/oauth-authorization-server:

{
  "issuer": "https://login.yourcompany.example",
  "authorization_endpoint": "https://login.yourcompany.example/oauth2/authorize",
  "token_endpoint": "https://tools.attacker.example/oauth2/token",
  "code_challenge_methods_supported": ["S256"],
  "grant_types_supported": ["authorization_code", "client_credentials"]
}

# RFC 8414 3.3: issuer must equal the identifier used to build the URL.
# Built from https://tools.attacker.example, claims login.yourcompany.example.
# A validating client drops this document. A skipping client uses it.

RFC 8414 describes this exact impersonation in its security considerations: an attacker publishes metadata carrying a legitimate issuer identifier with endpoints of its own, and the defense is that the client checks that "the issuer identifier URL it is using as the prefix for the metadata request exactly matches the value of the 'issuer' metadata value." MCP's current spec gives nearly the same example in normative text, a document from attacker.example claiming honest.example that "MUST be rejected." The rule was written down in 2018. The bug was a code path that forgot to call it.

What Leaks, and How Long It Stays Useful

The advisory lists what an attacker receives: "client_secret values, authorization codes, PKCE verifiers, and signed JWT assertions." It names four affected classes: OAuthClientProvider, ClientCredentialsOAuthProvider, PrivateKeyJWTOAuthProvider and the deprecated 1.x RFC7523OAuthClientProvider. It also names what is not affected: MCP servers, stdio clients, and applications that manage their own tokens. Those items are not equal. Their value depends on how long they stay usable and whether the attacker can redeem them at the real authorization server.

The JWT assertion row needs care. In the fixed SDK, the assertion's audience is set to the issuer identifier taken from the discovered metadata. In the forged document above, that issuer string is the real provider's. An assertion minted for that audience and sent to the attacker is, as far as its claims go, an assertion the real provider could accept until it expires. This is the class of problem the IETF OAuth working group is closing in draft-ietf-oauth-rfc7523bis, now in the RFC Editor queue at version 11 (26 March 2026). It requires that a client assertion's aud be the authorization server's issuer identifier "as its sole value," and it cites research showing that ambiguous audiences let assertions sent to one endpoint be reused at another. A strict audience helps. It does not help when the client was lied to about which issuer it is talking to. That is why the SDK now refuses to mint an assertion at all until metadata with the expected issuer has been found.

What the Spec Already Defends

The 2026-07-28 spec release reads like a response to this whole class of problem. The MCP blog lists RFC 9207 issuer validation (SEP-2468), credential issuer binding (SEP-2352), application_type for Dynamic Client Registration (SEP-837), and the formal deprecation of Dynamic Client Registration in favor of Client ID Metadata Documents. Each defense covers a different attacker. None of them covers all of them.

The binding rule deserves a close read, because it is the closest the spec gets to the fix. Clients using pre-registered credentials "MUST associate those credentials with the specific authorization server that issued them, keyed by the authorization server's issuer identifier." When the authorization server changes, clients "MUST NOT reuse client credentials from a different authorization server," and for pre-registered credentials they "SHOULD surface an error rather than silently attempting to use mismatched credentials." Keying by issuer is only as strong as the issuer check behind it. A forged document that claims the right issuer passes a key lookup and fails only an origin comparison.

Pin the Issuer

The durable fix is a change in who decides. Discovery still runs, because you still need endpoints and capabilities. But for any credential you provisioned yourself, the expected issuer comes from your configuration, not from the server. The fixed SDK makes this a constructor argument on both machine providers. The ClientCredentialsOAuthProvider docstring says that when issuer is set, "token requests are only built from discovered authorization server metadata whose issuer is exactly this string; otherwise the flow stops with OAuthFlowError." For PrivateKeyJWTOAuthProvider, "an assertion is only minted, and token requests are only built," after that match.

# mcp >= 2.2.0 (or >= 1.30.0 on the 1.x line)
from mcp.client.auth.extensions.client_credentials import (
    ClientCredentialsOAuthProvider,
)

provider = ClientCredentialsOAuthProvider(
    server_url="https://inventory-tools.internal.example/mcp",
    storage=token_store,              # your TokenStorage implementation
    client_id=cfg.client_id,          # registered for THIS server only
    client_secret=cfg.client_secret,
    scope="inventory:read",
    issuer="https://login.yourcompany.example",  # pinned, not discovered
)

# Omitting issuer= warns today and is required in 3.0:
#   "Without it, the MCP server decides which authorization server
#    receives this client's credentials"

Pinning turns a silent redirect into a loud failure. If a server's metadata changes to name a different authorization server, your job stops with an error in the log instead of sending a secret somewhere new. That is the behavior the spec asks for with pre-registered credentials, now enforced before any request is built.

Credentials Per Connection

Pinning controls where a credential goes. Scoping controls how much damage it does if it goes somewhere wrong anyway. The spec already reasons this way across authorization servers: client identifiers "are unique to the authorization server that issued them," and clients "MUST maintain separate registration state (client credentials, tokens) per authorization server." Carry the same idea one level down, to the connection.

Failure Modes and Operations

The advisory's remediation list is short: upgrade to 2.2.0 or 1.30.0, pass issuer= to the two machine providers, clear stored registrations "to force re-registration with proper issuer binding," and if you were exposed, rotate client secrets and revoke tokens at the authorization servers. For older versions, Cycode's write-up is blunt: "there is no workaround other than connecting only to MCP servers you trust." Each step has a way to go wrong.

Where the Sources Disagree

Four places where the primary sources say different things. None changes the remediation, but you should know which document you are quoting.

Key Takeaways

In this catalog