Inside the Harness: MCP's OAuth Issuer Binding, and Why Protocol Security Lives in String Comparison

Three numbers, then I'll explain them. One: the issuer field in an OAuth metadata document is a single string. Two: this summer, Atlassian, Context7 and Home Assistant have each served MCP authorization metadata where that string didn't match the URL it was fetched from, and strict clients refused to connect. Three: the fix now shipping in the MCP specification is, at its core, "compare the string, reject if it differs." That's the whole mechanism, and the attack it closes is one of the nastiest in OAuth: the mix-up attack, made structurally worse by the way MCP deploys.

This is an Inside the Harness piece, so we're going into the plumbing: what the issuer-binding problem is, which flows it affects, and what the 2026-07-28 specification package requires of anyone building an MCP client or server. The stateless-transport changes in the same release got the headlines; the auth hardening got six SEPs and almost no coverage. That's backwards, because if you run MCP servers holding real credentials, this is the part that decides whether a confused client hands a token to the wrong party.

Key Takeaways - MCP inverts OAuth's classic shape: one client talking to many authorization servers, discovered at runtime. That inversion is exactly the topology mix-up attacks were designed for. - The 2026-07-28 spec package is six SEPs. The two that matter most: SEP-2468 (validate the iss parameter on authorization responses, per RFC 9207) and SEP-2352 (bind every registered client credential to the issuer that minted it). - This isn't theoretical. Atlassian's and Context7's MCP endpoints have served issuer-mismatched metadata in the wild this summer, breaking strict clients; the spec is catching up to failures already in production. - iss validation is recommended now and heading towards mandatory. Build it in today, and treat a missing iss from a server that should support it as a rejection, not a shrug. - Even fully adopted, this package only hardens client-to-server authentication. Agent identity, per-request authorization, delegation provenance and audit remain outside the protocol, on you.

What happened

On 21 May 2026 the MCP maintainers locked the release candidate for the 2026-07-28 specification, the final spec shipped on 28 July, and SDK maintainers have been in a ten-week validation window since. Most commentary went to the stateless shift. Sitting underneath it, per Tigera's close read of the release, is a package of six Spec Enhancement Proposals hardening the OAuth layer:

The three housekeeping SEPs (2207, 2350, 2351) are clarifications, and clarifications in auth specs matter: two SDKs disagreeing about where a metadata document lives is an interop outage, not a footnote. But the load-bearing pair are 2468 and 2352, both about the same question: how does a client know which server it's actually talking to?

The MCP 2026-07-28 specification package contains six SEPs of OAuth hardening: issuer validation (2468), issuer-bound credentials (2352), client type declaration in Dynamic Client Registration (837), plus documented refresh tokens (2207), scope accumulation (2350) and discovery behaviour (2351), per Tigera's analysis. The release candidate locked on 21 May and the final spec shipped on 28 July 2026.

The vulnerability model: one client, many issuers

Classic OAuth assumes many clients, one authorization server: thousands of apps, one identity provider, one token issuer. Mix-up attacks, where a client is tricked into attributing an authorization response to the wrong server, were a niche concern because most clients only ever talked to one issuer.

MCP runs the whole thing backwards. One client, the host application, talks to many MCP servers, each potentially fronted by a different authorization server, discovered at runtime, and often registered on the fly via Dynamic Client Registration. The spec authors say it directly: the issuer-validation SEP targets "a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern," as Tigera's write-up quotes it. When your client holds registrations with a dozen authorization servers at once, an attacker doesn't need to break any crypto. They need your client to attribute a response to the wrong server.

Here's the shape of it. Your agent's host is mid-flow with honest server A when a response arrives that actually came from attacker-controlled server B. Without issuer checking, the client can complete the exchange against B, leaking the authorization code, or accept tokens minted by B and present them onward. RFC 9207, the 2021 fix for classic OAuth, added an explicit iss parameter to authorization responses so the client can reject anything from an unexpected issuer, and SEP-2468 pulls that requirement into MCP. SEP-2352 handles the quieter half: credentials. Before it, a client could hold a client ID minted by issuer A and, when a resource migrated to issuer B, present A's credential to B. Sometimes it worked, and "sometimes it worked" is not a property you want in an auth system. So 2352 requires registrations to be kept per authorization server, bound to the issuer value, and re-registered on migration.

This is also not the first pass at the class. The 2025-06-18 spec revision made Resource Indicators (RFC 8707) mandatory so tokens are minted for one specific server, and the MCP authorization spec already forbids accepting tokens meant for other resources or passing them through downstream. The 2026-07-28 package continues the same trajectory: less trust by default, more explicit binding. If you've read my MCP versus API piece, this is the cost of the flexibility I described there: runtime discovery makes MCP composable, and it also manufactures these identity questions.

MCP's one-client-many-servers topology is exactly the deployment pattern mix-up attacks target: an attacker doesn't break the crypto, they get the client to attribute a response or a credential to the wrong authorization server. SEP-2468 binds responses to issuers via RFC 9207's iss parameter; SEP-2352 binds registered credentials to their issuing server, per Tigera's analysis and RFC 9207.

The spec is catching up to production failures

If this all sounds abstract, it isn't. The issuer string has been failing in real MCP deployments all summer, and strict clients are already tripping over it.

In July, users of the opencode client found OAuth to Atlassian's Rovo MCP server failing at discovery. The protected-resource metadata correctly advertised a tenant-specific authorization server, but the metadata document served there declared the bare shared issuer https://auth.atlassian.com instead of the tenant path it was fetched from. RFC 8414 section 3.3 says the issuer value must exactly equal the URL used to retrieve the metadata, minus the .well-known suffix, so opencode's strict validation correctly rejected it and login was fully blocked: an Atlassian-side spec-compliance bug, confirmed against live endpoints. Context7's MCP endpoint hit a sibling bug in June, where the advertised authorization server and the metadata issuer on a Clerk subdomain disagreed, and the official MCP Go SDK refused the flow. Home Assistant's metadata omitted the issuer field entirely, breaking MCP clients a different way.

None of these three was a mix-up exploit; they were interoperability failures. But that's the point. The same string comparison that blocks an attacker's fake server also blocks a sloppy real one, so the ecosystem is about to get much less tolerant of metadata that was always wrong and previously got a pass. WorkOS's write-up of mix-up attacks makes the operational point well: many OAuth libraries still leave RFC 9207 checking off by default, and it points to CVE-2026-59208 as a case where scoping account lookups to the confirmed issuer, rather than matching a sub claim globally, would have stopped the bug outright. I'd treat that CVE reference as reported by WorkOS rather than independently verified, but the defensive principle is standard practice either way.

Real MCP deployments have been failing issuer validation all summer: Atlassian's Rovo MCP server serves metadata whose issuer doesn't match the tenant URL it was fetched from (opencode issue #39332), Context7's endpoint advertised one authorization server while its metadata declared another (Context7 issue #2723), and Home Assistant omitted the issuer field entirely. RFC 8414 section 3.3 requires the issuer value to exactly match the retrieval URL, so strict clients correctly rejected all three.

What implementers must do

If you maintain an MCP client:

1. Validate iss on every authorization response now. Reject mismatches with the issuer you're mid-flow with, and if the server advertises RFC 9207 support but omits the parameter, reject that too. The spec is explicit that rejecting missing iss is coming in a future version, so treat it as mandatory today.

2. Partition registration state per authorization server. Every client ID, secret and refresh token gets stored against the issuer value that minted it. If a resource's protected-resource metadata starts pointing at a new authorization server, re-register; never replay the old credential.

3. Declare application_type in Dynamic Client Registration. SEP-837 fixes the class of failures where a desktop or CLI client gets defaulted to web and rejected for its localhost redirect URI. One field, real bug class gone.

4. Scope account lookups to the issuer. A sub claim should only ever match accounts within the namespace of the issuer you actually validated. Never match globally.

If you run an MCP server or an authorization server in front of one: serve metadata whose issuer exactly equals the URL it's retrieved from (tenant path included), implement protected-resource metadata per RFC 9728, and keep validating that tokens were minted for your resource specifically. And if you're self-hosting agents against a growing list of MCP servers, the fleet maths matters: N agents times M servers means N times M issuer-bound registrations. With ten agents that's a spreadsheet; with a hundred it's a registry, and the spec has no opinion about registries. That part's on your platform.

Implementers must validate iss on authorization responses (rejecting mismatches and, where supported, omissions), store credentials partitioned by issuer and re-register on migration, declare application_type during Dynamic Client Registration, and scope account lookups to the validated issuer, per Tigera's SEP analysis and WorkOS's mix-up guidance. Tier 1 SDKs are expected to ship support within the spec's ten-week validation window.

What the spec still doesn't answer

Read the package again and notice what all six SEPs have in common: they harden the exchange between one OAuth client and one authorization server. That needed doing. But as Tigera's analysis puts it plainly, the token authenticates the client, not the agent. Two hundred agents behind one host share one client identity; issuer binding says nothing about which agent, on whose behalf, deciding on the basis of what, is behind the client. Scopes are admission, not per-request policy. Delegation chains (agent calls agent calls server) can be OAuth-clean at every hop and unaccountable end to end. And nothing in the package requires anyone to write any of it down, which is the correct scoping decision for a protocol and an incomplete answer for an enterprise.

I don't say that to diminish the work. MCP without issuer validation was HTTP without certificate checking, and that hole is now closing. But the four gaps, agent identity, per-request authorization, delegation provenance and audit, are the governance layer, and they don't arrive by waiting for the spec. They're the same gaps I work through with clients on agent governance, and they're enforced by the environment around the agent or by nobody.

FAQ

What is the MCP OAuth issuer-binding issue?

MCP clients talk to many authorization servers discovered at runtime, which makes them vulnerable to mix-up attacks: a response or credential attributed to the wrong server. The 2026-07-28 spec fixes this by requiring clients to validate the iss parameter on authorization responses (SEP-2468, adopting RFC 9207) and to bind every registered credential to its issuer (SEP-2352).

Is this a vulnerability in MCP itself?

It's a class of vulnerability the protocol's deployment pattern made prevalent, now closed at spec level. The failures seen in production this summer (Atlassian, Context7, Home Assistant serving issuer-mismatched metadata) were implementation bugs, but they show how fragile the unvalidated model was. Strict validation is now the baseline.

Which flows are affected?

Authorization-code flows with any client registered against more than one authorization server, Dynamic Client Registration across servers, credential use after a resource migrates between authorization servers, and metadata discovery via .well-known documents. Single-server deployments were never the risk; the multi-server topology that agents create is.

When does this become mandatory?

The 2026-07-28 spec is final, SDK support is landing within a ten-week validation window from the May release-candidate lock, and the spec is explicit that rejecting responses without iss will be expected in a future version. Treat it as mandatory in anything you build now.

The bottom line

OAuth security is mostly boring string comparison with consequences, and MCP just had its reckoning with that fact. The 2026-07-28 package imports a five-year-old OAuth fix into a protocol whose one-client-many-servers shape made it urgent, just as real deployments started failing the check in the wild. Update your SDKs, validate iss, bind your registrations. Then ask the question the spec was right not to answer: when a token you issued gets used for a tool call you'd never have approved, presented by an agent you can't name, who catches it, and where's the record? That answer doesn't come from a specification. It comes from the harness you build around one.

If you're sorting out auth and identity for an MCP deployment, that's a conversation I have with clients regularly. Get in touch.

Sources

• Tigera, "MCP's Auth Hardening: What the Six New OAuth SEPs Fix, and What They Still Don't": https://www.tigera.io/blog/mcps-auth-hardening-what-the-six-new-oauth-seps-fix-and-what-they-still-dont/ (published 2026-07-28, retrieved 2026-08-29)

• WorkOS, "OAuth mix-up attacks and RFC 9207: The issuer check that never made it to token exchange": https://workos.com/blog/oauth-mix-up-attacks-rfc-9207 (published 2026-07-20, retrieved 2026-08-29)

• Model Context Protocol, Authorization specification: https://modelcontextprotocol.io/specification/2025-11-25/basic/authorization (published 2025-11-25, retrieved 2026-08-29)

• RFC Editor, RFC 9207, "OAuth 2.0 Authorization Server Issuer Identification": https://www.rfc-editor.org/rfc/rfc9207.html (published 2021-12-16, retrieved 2026-08-29)

• opencode repository, issue #39332, "MCP OAuth: Atlassian auth fails - RFC 8414 issuer mismatch": https://github.com/anomalyco/opencode/issues/39332 (published 2026-07-28, retrieved 2026-08-29)

• Context7 repository, issue #2723, "OAuth metadata issuer mismatch for MCP OAuth endpoint": https://github.com/upstash/context7/issues/2723 (published 2026-06-05, retrieved 2026-08-29)

• Home Assistant Core, issue #147059, missing issuer in OAuth metadata: https://github.com/home-assistant/core/issues/147059 (published 2025-06-17, retrieved 2026-08-29)

• modelcontextprotocol/modelcontextprotocol repository: https://github.com/modelcontextprotocol/modelcontextprotocol (retrieved 2026-08-29)