Come funziona l'autenticazione MCP? Audito della catena OAuth

Per un server MCP remoto protetto, authentication non è un controllo di token. Si tratta di una catena di autorizzazione: il cliente riceve una sfida, scopre i metadati per la risorsa protetta esatta, scopre e convalida un server di autorizzazione, ottiene un'identità del cliente, esegue un flusso di codice di autorizzazione con PKCE e un indicatore di risorsa, riceve gli ambiti richiesti e prova che il token risultante funziona al punto finale MCP previsto. Questa risposta ha un limite importante. L'attuale Specifica dell'autorizzazione MCP rende l'autorizzazione facoltativa e applica il suo percorso OAuth ai trasporti basati su HTTP. Un server STDIO locale dovrebbe invece ottenere le credenziali attraverso il suo ambiente ospitante o un altro meccanismo locale. L'avvio di un flusso di browser per ogni connessione MCP non è quindi un default ragionevole. La domanda operativa non è ho un token? è quali ricevute mostrano che ogni legame in questa particolare catena di autorizzazione è d'accordo? Una stringa a forma di token può coesistere con la risorsa sbagliata, un emittente non fidato, scope mancante o una richiesta protetta che restituisce comunque 401 . Inizia con il trasporto e la prima sfida Il Tutorial di autorizzazione MCP ufficiale spiega il flusso HTTP remoto in fasi. In forma condensata: 1. Il cliente invia una richiesta MCP senza token. 2. Il server MCP protetto restituisce 401 Unauthorized con una sfida Bearer WWW Authenticate . 3. La sfida punta ai metadati di risorse protette tramite resource metadata . 4. Tali metadati identificano la risorsa protetta e uno o più server di autorizzazione. 5. Il client raccoglie i metadati del server di autorizzazione e convalida l'emittente e gli endpoint. 6. Il client ottiene un ID client attraverso un meccanismo supportato dal server di autorizzazione, quindi esegue il flusso di codice di autorizzazione con PKCE e l'identificatore di risorse MCP. 7. Il cliente invia il token di accesso risultante al server MCP e osserva la richiesta protetta. Il primo 401 non è un fallimento di soppressione. E' una ricevuta per la scoperta. Un registro utile conserva lo stato HTTP, lo schema di autenticazione, l'URL dei metadati, il tempo di osservazione e la risorsa MCP selezionata. Znot conserva l'intestazione Authorization , i cookie, il codice di autorizzazione, il verificatore, il segreto del cliente o il token di accesso. RFC 9728 definisce i metadati delle risorse protette e il noto modello di scoperta. Il suo valore di sicurezza dipende dall'autorità: i metadati per https://mcp.example/mcp devono descrivere quella risorsa, non un host simile o un URL fornito da un servizio non correlato. Seguire un'URL di autorizzazione arbitraria da un corpo di errore non è equivalente. Il server di autorizzazione è un ruolo separato. Un server MCP protetto agisce come un server di risorse OAuth; il client MCP agisce come un client OAuth; il server di autorizzazione interagisce con l'utente quando necessario ed emette token di accesso. La confusione di questi ruoli rende plausibile un errore comune di risoluzione dei problemi: girare un token del resource server prima di verificare se il cliente ha scoperto l'emittente corretto. Legare la risorsa, l'emittente, il cliente e il flusso di codice Due URL meritano un confronto preciso. La prima è la risorsa protetta. RFC 8707 definisce il parametro di richiesta resource in modo che un server di autorizzazione sappia il destinatario previsto di un token. L'attuale progetto di MCP richiede il parametro delle risorse sia nelle richieste di autorizzazione che nelle richieste di token. Un token di accesso emesso per un'altra API non è quasi valido per il server MCP selezionato. Il secondo è l'emittente del server di autorizzazione. Prima di aprire il browser, un client registra l'emittente da metadati convalidati del server di autorizzazione. Quando una risposta di autorizzazione include iss , l'attuale progetto di MCP descrive il confronto con quel valore registrato prima che il cliente invia il codice a un endpoint token. Un'inadeguatezza dell'emittente è una condizione di arresto, non un motivo per provare lo stesso codice contro entrambi gli endpoint. La registrazione del cliente è anche un strato esplicito. Un cliente può utilizzare un documento di metadati di ID del cliente, un ID del cliente pre registrato o un percorso di registrazione dinamica supportato. L'attuale progetto tratta la registrazione dinamica dei clienti come un meccanismo di compatibilità piuttosto che come un presupposto universale. Se non esiste un meccanismo di registrazione supportato, il verdetto corretto è registration blocked ; l'invenzione di un URI di reindirizzo o il riutilizzo di un altro ID client di prodotto nasconderebbe il fallimento effettivo di interoperabilità. PKCE lega la richiesta di autorizzazione allo scambio di codici successivo. L'audit registra solo se il flusso ha mantenuto un verificatore vincolato, mai il verificatore stesso. Un collegamento mancante diventa unsafe flow , anche se un browser restituisce un codice. Ecco la forma senza contenuti utilizzata per un dispositivo sano: I nomi degli ambiti sono prove di configurazione, non valori segreti. In una distribuzione sensibile possono ancora rivelare le capacità, quindi conservare solo ciò di cui ha bisogno la decisione sanitaria e applicare gli stessi controlli di accesso come altri metadati operativi. Diagnosticare il primo strato fallito Una lista di controllo piatta produce azioni contraddittorie. Se i metadati di risorsa protetta non sono disponibili, il confronto con l'emittente non ha informazioni affidabili. Se l'identificatore di risorsa è errato, richiedere un ambito più ampio non può correggerlo. Il classificatore utilizza quindi la priorità e si ferma al primo strato fallito: Verdicto Le prove che hanno fermato la catena La prossima azione è limitata . not applicable Trasporti locali STDIO Utilizzare il meccanismo locale di credenziali runtime invalid challenge Mancano o non sono HTTPS resource metadata Ripara la sfida 401 metadata unavailable Metadati di risorsa protetta non sono stati restituiti a 200 Restaurare i metadati; non indovinare l'emittente resource mismatch Metadati o token mirano a una risorsa diversa Correzione dell'identità delle risorse o richiesta di un token legato alle risorse issuer mismatch Discovered o callback emittente non è d'accordo Rifiutare il flusso e esaminare l'autorità dei metadati registration blocked Nessuna identità di cliente supportata Configurazione di un meccanismo di registrazione supportato unsafe flow Il flusso di codici di autorizzazione non è legato a PKCE Rilancio con PKCE step up required L'operazione attuale ha bisogno di un ambito non consentito Richiedere solo l'ambito di applicazione mancante contestato token rejected Le obbligazioni concordano, ma la richiesta protetta non riesce Classificare la nuova sfida prima di rotare authorized ready Tutte le ricevute di autorizzazione concordano e la richiesta riesce Proseguire con l'inizializzazione e i controlli di risultato del MCP L'apparecchio fornito può essere riprodotto senza accesso alla rete: La sua data di esecuzione ha prodotto dieci casi, dieci verdetti di primo livello, uno authorized ready e uno secretFieldsStored: 0 . Questo risultato è intenzionalmente più severo di 9 errori e un successo. Essa dimostra che la regola decisionale conserva significative differenze tra un trasporto locale, scoperta fallita, identità contraddittoria, registrazione non supportata, flusso di codice non sicuro, scopo mancante e token rifiutato. La regola del primo strato fallito limita anche i tentativi di ripetizione. metadata unavailable può giustificare un nuovo tentativo di metadati limitati. issuer mismatch non dovrebbe. step up required può giustificare un nuovo flusso di consenso per l'ambito di applicazione contestato. token rejected richiede la lettura della nuova sfida perché la scadenza, la revoca, il pubblico e la portata non condividono una sola riparazione. Mantenere la portata di incremento separata dal fallimento del token L'attuale progetto di MCP raccomanda che un server inclua la portata richiesta nella sua sfida WWW Authenticate . L'ambito di applicazione contestato per l'operazione corrente è autorizzato per tale operazione; non deve essere uguale a tutti i metadati della risorsa set scopes supported . Ciò modifica la decisione dell'operatore. Supponiamo che una lettura abbia successo con files:read , allora una scrittura restituisce 403 e sfide per files:write . Questo non è la prova che il negozio di simboli sia corrotto. E' uno stato step up required . Il cliente dovrebbe chiedere il permesso mancante con visibilità umana e conservare i permessi ancora necessari per altre operazioni. Al contrario, una richiesta protetta che restituisce 401 dopo che le ricevute di risorsa, l'emittente, la registrazione, il PKCE e il campo di applicazione sono concordate è token rejected . Il prossimo passo sicuro e' classificare la nuova sfida. Presentare ripetutamente lo stesso segno è attività, non progresso. Rotare ogni credenziale può anche distruggere prove utili e interrompere i clienti sani. Il verdetto di authorized ready rimane ristretto. Dice che il server remoto MCP ha accettato la catena di autorizzazione per questa richiesta. Non dice: L'inizializzazione del MCP e la negoziazione delle capacità hanno avuto successo; lo strumento selezionato esiste ancora o il suo schema è invariato; un invito di strumento ha prodotto l'effetto esterno previsto; un effetto collaterale è sicuro per riprovare dopo un intervallo di tempo; l'esistenza di un prodotto di consegna dell'utente; il server, il client e la risorsa di autorizzazione sono affidabili a livello globale. Queste sono decisioni successive in materia di salute e sicurezza. Una richiesta protetta di successo dovrebbe spostare l'esecuzione nei controlli del ciclo di vita del MCP, quindi nella verifica degli effetti degli strumenti e dei risultati non direttamente all'agente sano. Utilizzare la ricevuta senza raccogliere credenziali Per le operazioni di produzione, immagazzinare hash o ID stabili per il client e la risorsa selezionati solo quando sono necessari per correlare gli eventi. Registrare i timestamp e la versione delle specifiche perché i metadati e le regole del protocollo evolvono. Mantenere il token grezzo, il codice, il verificatore, il segreto, il cookie, il prompt, gli argomenti degli strumenti e i risultati degli strumenti fuori dal registro sanitario. L'artefatto e' un classificatore, non una suite live. Si affida alle osservazioni che gli sono state fornite. Un'implementazione reale deve inoltre convalidare TLS, origine dei metadati, redirect URI, comportamento dell'emittente, firme di token o introspezione, pubblico, scadenza e politica di distribuzione. Il progetto del MCP è stato verificato il 30 luglio 2026; inserire la specifica che si implementa e riattivare il dispositivo quando il contratto cambia. Il territorio previsto del prodotto Sidewisp comprende la disponibilità degli strumenti, le credenziali scadute, la perdita di autorizzazione, i progressi utili e la verifica dei risultati. Sidewisp è attualmente in anteprima privata. Gli adattatori di monitoraggio della produzione e l'esecutore di recupero non sono generalmente spediti, quindi questo articolo fornisce una regola operativa indipendente piuttosto che sostenere che Sidewisp esegui già questo audit di autorizzazione MCP. La risposta pratica a come funziona l'autenticazione MCP? è quindi una catena di ricevute di autorizzazione, non un screenshot del token portatore. Trattare la prima contraddizione come diagnosi, applicare una riparazione limitata e mantenere il successo dell'autorizzazione separato dal successo dello strumento e dal risultato finale dell'utente.