Inside the Harness: l'issuer binding OAuth di MCP e perché la sicurezza dei protocolli vive nel confronto tra stringhe

Tre numeri, poi li spiego. Uno: il campo issuer in un documento di metadata OAuth è una singola stringa. Due: questa estate Atlassian, Context7 e Home Assistant hanno tutti servito metadata di autorizzazione MCP in cui quella stringa non corrispondeva all'URL da cui il documento era stato recuperato, e client rigorosi hanno rifiutato la connessione. Tre: la correzione ora in arrivo nella specifica MCP è, nella sostanza, "confronta la stringa, rifiuta se differisce". Questo è l'intero meccanismo, e l'attacco che chiude è uno dei più sgradevoli di OAuth: il mix-up attack, reso strutturalmente peggiore dal modo in cui MCP viene distribuito.

Questo è un pezzo Inside the Harness, quindi entriamo nelle tubature: qual è il problema dell'issuer binding, quali flow coinvolge e cosa richiede il pacchetto di specifica 2026-07-28 a chiunque costruisca un client o server MCP. I cambiamenti al trasporto stateless nella stessa release hanno preso i titoli; l'hardening auth ha ricevuto sei SEP e quasi nessuna copertura. È il contrario di quello che dovrebbe essere, perché se gestite server MCP con credenziali reali, questa è la parte che decide se un client confuso consegna un token alla parte sbagliata.

Punti chiave - MCP inverte la forma classica di OAuth: un client che parla con molti authorization server, scoperti a runtime. Questa inversione è esattamente la topologia per cui sono stati progettati i mix-up attack. - Il pacchetto di specifica 2026-07-28 contiene sei SEP. Le due più importanti: SEP-2468, che valida il parametro iss nelle authorization response secondo RFC 9207, e SEP-2352, che lega ogni client credential registrata all'issuer che l'ha emessa. - Non è teoria. Gli endpoint MCP di Atlassian e Context7 hanno servito questa estate metadata con issuer mismatch, rompendo client rigorosi; la specifica sta recuperando errori già presenti in produzione. - La validazione di iss è raccomandata ora e si sta muovendo verso l'obbligatorietà. Implementatela oggi e trattate un iss mancante da un server che dovrebbe supportarlo come rifiuto, non come una spallata. - Anche se adottato completamente, questo pacchetto rafforza solo l'autenticazione client-server. Agent identity, authorization per request, delegation provenance e audit restano fuori dal protocollo, quindi a carico vostro.

Cosa è successo

Il 21 maggio 2026 i maintainer MCP hanno bloccato il release candidate della specifica 2026-07-28, la specifica finale è uscita il 28 luglio e da allora i maintainer degli SDK sono in una finestra di validazione di dieci settimane. La maggior parte dei commenti si è concentrata sul passaggio stateless. Sotto, secondo la lettura approfondita di Tigera, c'è un pacchetto di sei Spec Enhancement Proposal che rafforzano il layer OAuth:

Le tre SEP di housekeeping, 2207, 2350 e 2351, sono chiarimenti, e i chiarimenti nelle specifiche auth contano: due SDK che non concordano su dove viva un documento metadata causano un outage di interoperabilità, non una nota a piè pagina. Ma la coppia portante è 2468 e 2352, entrambe sulla stessa domanda: come fa un client a sapere con quale server sta davvero parlando?

Il pacchetto di specifica MCP 2026-07-28 contiene sei SEP di hardening OAuth: validazione dell'issuer (2468), credenziali legate all'issuer (2352), dichiarazione del tipo client in Dynamic Client Registration (837), più refresh token documentati (2207), accumulazione scope (2350) e comportamento discovery (2351), secondo l'analisi di Tigera. Il release candidate è stato bloccato il 21 maggio e la specifica finale è uscita il 28 luglio 2026.

Il modello della vulnerabilità: un client, molti issuer

OAuth classico presume molti client e un authorization server: migliaia di app, un identity provider, un token issuer. I mix-up attack, in cui un client viene ingannato ad attribuire una authorization response al server sbagliato, erano una preoccupazione di nicchia perché la maggior parte dei client parlava con un solo issuer.

MCP esegue tutto al contrario. Un client, la host application, parla con molti server MCP, ciascuno potenzialmente davanti a un authorization server diverso, scoperto a runtime e spesso registrato al volo tramite Dynamic Client Registration. Gli autori della specifica lo dicono direttamente: la SEP di issuer validation prende di mira "a class of mix-up attack that is more prevalent in MCP's single-client, many-server deployment pattern", come cita l'articolo di Tigera. Quando il vostro client mantiene registrazioni con una dozzina di authorization server contemporaneamente, un attaccante non deve rompere la crittografia. Deve far sì che il client attribuisca una risposta al server sbagliato.

La forma è questa. L'host del vostro agent è a metà flow con il server onesto A quando arriva una risposta che in realtà proviene dal server B controllato dall'attaccante. Senza controllo dell'issuer, il client può completare l'exchange contro B, facendo leak dell'authorization code, oppure accettare token emessi da B e presentarli in seguito. RFC 9207, la correzione del 2021 per OAuth classico, ha aggiunto un parametro esplicito iss alle authorization response in modo che il client possa rifiutare tutto ciò che proviene da un issuer inatteso, e SEP-2468 porta questo requisito in MCP. SEP-2352 gestisce l'altra metà, più silenziosa: le credenziali. Prima, un client poteva detenere un client ID emesso dall'issuer A e, quando una resource migrava all'issuer B, presentare la credential di A a B. A volte funzionava, e "a volte funziona" non è una proprietà desiderabile in un sistema auth. Per questo 2352 richiede che le registrazioni siano mantenute per authorization server, legate al valore issuer e rifatte dopo una migrazione.

Non è nemmeno il primo intervento su questa classe. La revisione di specifica 2025-06-18 ha reso obbligatori i Resource Indicators RFC 8707, così i token vengono emessi per un server specifico, e la specifica di autorizzazione MCP vieta già di accettare token destinati ad altre resource o passarli downstream. Il pacchetto 2026-07-28 continua la stessa traiettoria: meno fiducia per default, più binding esplicito. Se avete letto il mio pezzo MCP versus API, questo è il costo della flessibilità che descrivevo: runtime discovery rende MCP componibile e allo stesso tempo crea queste domande di identity.

La topologia one-client-many-servers di MCP è esattamente il deployment pattern preso di mira dai mix-up attack: un attaccante non rompe la crypto, porta il client ad attribuire una response o una credential all'authorization server sbagliato. SEP-2468 lega le response agli issuer tramite il parametro iss di RFC 9207; SEP-2352 lega le credenziali registrate al server che le ha emesse, secondo l'analisi di Tigera e RFC 9207.

La specifica sta recuperando failure di produzione

Se tutto ciò sembra astratto, non lo è. La stringa issuer sta già fallendo in deployment MCP reali per tutta l'estate, e client rigorosi ci stanno inciampando.

A luglio, utenti del client opencode hanno scoperto che OAuth verso il server MCP Rovo di Atlassian falliva alla discovery. I protected-resource metadata annunciavano correttamente un authorization server specifico del tenant, ma il documento metadata servito lì dichiarava l'issuer condiviso nudo https://auth.atlassian.com invece del path tenant da cui era stato recuperato. RFC 8414 sezione 3.3 dice che il valore issuer deve essere esattamente uguale all'URL usato per recuperare i metadata, meno il suffisso .well-known, quindi la validazione rigorosa di opencode lo ha correttamente rifiutato e il login è stato completamente bloccato: un bug di conformità alla specifica lato Atlassian, confermato contro endpoint live. L'endpoint MCP di Context7 ha avuto un bug affine a giugno, in cui l'authorization server annunciato e il metadata issuer su un sottodominio Clerk non corrispondevano, e l'SDK Go ufficiale MCP ha rifiutato il flow. I metadata di Home Assistant omettevano del tutto il campo issuer, rompendo i client MCP in un altro modo.

Nessuno dei tre era un exploit mix-up; erano failure di interoperabilità. Ma è proprio questo il punto. Lo stesso confronto tra stringhe che blocca il server falso di un attaccante blocca anche un server reale configurato male, quindi l'ecosistema sta per diventare molto meno tollerante verso metadata che sono sempre stati sbagliati ma prima passavano. L'articolo WorkOS sui mix-up attack rende bene il punto operativo: molte librerie OAuth lasciano ancora disattivato per default il controllo RFC 9207, e cita CVE-2026-59208 come caso in cui limitare gli account lookup all'issuer confermato, invece di fare match globale su un claim sub, avrebbe fermato il bug. Tratterei quel riferimento CVE come riportato da WorkOS piuttosto che verificato indipendentemente, ma il principio difensivo resta comunque una pratica standard.

Deployment MCP reali hanno fallito issuer validation per tutta l'estate: il server MCP Rovo di Atlassian serve metadata il cui issuer non corrisponde all'URL tenant da cui sono stati recuperati (opencode issue #39332), l'endpoint Context7 annunciava un authorization server mentre i metadata ne dichiaravano un altro (Context7 issue #2723), e Home Assistant ometteva del tutto il campo issuer. RFC 8414 sezione 3.3 richiede che il valore issuer corrisponda esattamente alla retrieval URL, quindi i client rigorosi hanno correttamente rifiutato tutti e tre.

Cosa devono fare gli implementatori

Se mantenete un client MCP:

1. Validate iss su ogni authorization response da subito. Rifiutate mismatch rispetto all'issuer con cui siete a metà flow e, se il server dichiara supporto RFC 9207 ma omette il parametro, rifiutate anche quello. La specifica è esplicita che il rifiuto di iss mancante arriverà in una futura versione, quindi trattatelo come obbligatorio oggi.

2. Partizionate lo stato di registrazione per authorization server. Ogni client ID, secret e refresh token viene memorizzato insieme all'issuer che l'ha emesso. Se i protected-resource metadata di una resource iniziano a puntare a un nuovo authorization server, registrate di nuovo; non ripresentate mai la vecchia credential.

3. Dichiarate application_type durante Dynamic Client Registration. SEP-837 risolve la classe di failure in cui un client desktop o CLI viene considerato web per default e rifiutato per la sua localhost redirect URI. Un campo, una vera classe di bug eliminata.

4. Limitate gli account lookup all'issuer. Un claim sub deve fare match solo con account nel namespace dell'issuer effettivamente validato. Mai match globale.

Se gestite un server MCP o un authorization server davanti a uno: servite metadata il cui issuer corrisponde esattamente all'URL da cui vengono recuperati, path tenant incluso, implementate protected-resource metadata secondo RFC 9728 e continuate a validare che i token siano stati emessi specificamente per la vostra resource. E se state self-hosting agents contro una lista crescente di server MCP, la matematica della fleet conta: N agents per M servers significa N per M registrazioni legate agli issuer. Con dieci agents è uno spreadsheet; con cento è un registry, e la specifica non ha opinioni sui registry. Quella parte tocca alla vostra piattaforma.

Gli implementatori devono validare iss nelle authorization response, rifiutando mismatch e, dove supportato, omissioni, conservare le credenziali partizionate per issuer e registrarsi di nuovo dopo migrazione, dichiarare application_type durante Dynamic Client Registration e limitare gli account lookup all'issuer validato, secondo l'analisi SEP di Tigera e la guida WorkOS ai mix-up. Gli SDK Tier 1 dovrebbero fornire supporto entro la finestra di validazione di dieci settimane della specifica.

Cosa la specifica ancora non risponde

Rileggete il pacchetto e notate cosa hanno in comune tutte e sei le SEP: rafforzano lo scambio tra un client OAuth e un authorization server. Era necessario. Ma come dice chiaramente l'analisi di Tigera, il token autentica il client, non l'agent. Duecento agents dietro un host condividono una client identity; issuer binding non dice nulla su quale agent, per conto di chi, decidendo sulla base di cosa, sia dietro il client. Gli scope sono admission, non policy per request. Le delegation chain, agent chiama agent chiama server, possono essere OAuth-clean a ogni hop e non accountable end-to-end. E niente nel pacchetto richiede che qualcuno scriva tutto questo, che è la decisione corretta di scope per un protocollo e una risposta incompleta per un'impresa.

Non lo dico per sminuire il lavoro. MCP senza issuer validation era HTTP senza certificate checking, e quel buco ora si sta chiudendo. Ma i quattro gap, agent identity, per-request authorization, delegation provenance e audit, sono il layer di governance, e non arrivano aspettando la specifica. Sono gli stessi gap che lavoro con i clienti in agent governance, e vengono enforced dall'environment attorno all'agent oppure da nessuno.

FAQ

Qual è il problema di OAuth issuer binding in MCP?

I client MCP parlano con molti authorization server scoperti a runtime, il che li rende vulnerabili ai mix-up attack: una response o credential attribuita al server sbagliato. La specifica 2026-07-28 lo corregge richiedendo ai client di validare il parametro iss nelle authorization response, SEP-2468 adottando RFC 9207, e di legare ogni credential registrata al proprio issuer, SEP-2352.

È una vulnerabilità di MCP stesso?

È una classe di vulnerabilità resa più frequente dal deployment pattern del protocollo, ora chiusa a livello di specifica. I failure visti in produzione questa estate, Atlassian, Context7 e Home Assistant con issuer-mismatched metadata, erano bug di implementazione, ma mostrano quanto fosse fragile il modello non validato. La validazione rigorosa è ora la baseline.

Quali flow sono interessati?

Authorization-code flow con qualunque client registrato presso più di un authorization server, Dynamic Client Registration tra server, uso delle credenziali dopo che una resource migra tra authorization server e metadata discovery tramite documenti .well-known. I deployment a singolo server non sono mai stati il rischio; lo è la topologia multi-server che gli agents creano.

Quando diventa obbligatorio?

La specifica 2026-07-28 è finale, il supporto SDK sta arrivando entro una finestra di validazione di dieci settimane dal lock del release candidate di maggio, e la specifica è esplicita che rifiutare response senza iss sarà previsto in una futura versione. Trattatelo come obbligatorio in tutto ciò che costruite ora.

In sintesi

La sicurezza OAuth è in gran parte noioso confronto tra stringhe con conseguenze, e MCP ha appena fatto i conti con questo fatto. Il pacchetto 2026-07-28 importa una correzione OAuth vecchia di cinque anni in un protocollo la cui forma one-client-many-servers l'ha resa urgente, proprio mentre deployment reali iniziavano a fallire il controllo sul campo. Aggiornate gli SDK, validate iss, legate le registrazioni. Poi fate la domanda che la specifica ha fatto bene a non rispondere: quando un token che avete emesso viene usato per una tool call che non avreste mai approvato, presentata da un agent che non sapete nominare, chi la intercetta e dov'è il record? La risposta non arriva da una specifica. Arriva dall'harness che costruite attorno.

Se state sistemando auth e identity per un deployment MCP, è una conversazione che faccio regolarmente con i clienti. Contattatemi.

Fonti

• 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/ (pubblicato 2026-07-28, consultato 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 (pubblicato 2026-07-20, consultato 2026-08-29)

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

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

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

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

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

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