Recensione approfondita della specifica di autorizzazione MCP (edizione 2025-03-26)

MCP (Model Context Protocol) è uno standard aperto che consente ai modelli di IA di interagire con strumenti e servizi esterni. È ampiamente adottato dall'industria. Poiché MCP supporta metodi di trasporto basati su HTTP, il server MCP remoto giocherà un ruolo sempre più importante nell'ecosistema MCP.

A differenza del server MCP locale, che consente a ciascun utente di eseguire la propria istanza del server, il server MCP remoto richiede a tutti gli utenti di condividere lo stesso servizio server MCP. Questo porta al problema principale che la specifica di autorizzazione MCP mira a risolvere: come consentire al server MCP di accedere alle risorse dell'utente per conto dell'utente.

Questo articolo analizzerà in profondità la specifica di autorizzazione MCP. Ti aiuterà a comprendere i principi di progettazione della specifica di autorizzazione MCP e alcune direzioni per l'implementazione dell'autorizzazione MCP. Poiché questa specifica è ancora in evoluzione, condividerò alcuni pensieri basati sulla mia esperienza personale nell'implementazione di Authenticator, tra cui:

• Vantaggi e limiti di OAuth 2.1 come quadro di autorizzazione
• Sfide dei doppi ruoli del server MCP come server di autorizzazione e server di risorse
• Complessità pratica di implementare un server di autorizzazione completo
• Analisi degli scenari adatti per l'autorizzazione delegata di terze parti
• Compromessi pratici della registrazione dinamica dei client
• Importanza di definire chiaramente i limiti delle risorse del server MCP

Panoramica della specifica di autorizzazione MCP#

La specifica di autorizzazione MCP definisce il processo di autenticazione tra server MCP (remoto) e client MCP.

Penso che basare questa specifica su OAuth 2.1 sia una scelta molto ragionevole. OAuth come framework di protocollo di autorizzazione risolve il problema di come consentire agli utenti di autorizzare applicazioni di terze parti ad accedere alle risorse degli utenti per loro conto. Se non sei familiare con OAuth, puoi controllare AuthWiki-OAuth per ulteriori informazioni.

Nello scenario del client MCP e del server MCP, riguarda "gli utenti che autorizzano il client MCP ad accedere alle risorse degli utenti sul server MCP". Le "risorse degli utenti sul server MCP" attualmente si riferiscono principalmente agli strumenti forniti dal server MCP o alle risorse fornite dai servizi backend del server MCP.

Per implementare il processo di autenticazione OAuth 2.1, il protocollo richiede a un server MCP di fornire le seguenti interfacce per lavorare con il client MCP per completare il processo di autenticazione OAuth 2.1:

• /.well-known/oauth-authorization-server: meta dati del server OAuth
• /authorize: endpoint di autorizzazione, utilizzato per richieste di autorizzazione
• /token: endpoint di token, utilizzato per lo scambio e il rinnovo dei token
• /register: endpoint di registrazione del client, utilizzato per la registrazione dinamica del client

Il processo di autenticazione è il seguente:

La specifica specifica anche come il server MCP supporta l'autorizzazione delegata tramite server di autorizzazione di terze parti.

Il flusso di esempio nella specifica è il seguente (dal contenuto del documento):

In questo scenario, sebbene il server MCP delega l'autorizzazione a un server di autorizzazione di terze parti, il server MCP agisce ancora come un server di autorizzazione per il client MCP. Questo perché il server MCP deve emettere il proprio token di accesso al client MCP.

A mio avviso, questo scenario sembra più adatto per gestire situazioni in cui il server MCP funge da intermediario per il client MCP (utente) per accedere a risorse di terze parti (come i repository GitHub), piuttosto che fare da intermediario per il client MCP (utente) per accedere alle proprie risorse del server MCP.

In sintesi, secondo il protocollo, il server MCP svolge entrambi i ruoli di server di autorizzazione e server di risorse in OAuth.

Successivamente, discutiamo delle responsabilità del server MCP come server di autorizzazione e server di risorse.

Server MCP come servizio di autorizzazione#

Quando il server MCP agisce come server di autorizzazione, significa che l'utente finale del client MCP ha una propria identità sul server MCP. Il server MCP è responsabile della autenticazione di questo utente finale e dell'emissione di un token di accesso a questo utente finale per accedere alle risorse del server MCP.

Le interfacce relative all'autorizzazione richieste dalla specifica di autorizzazione MCP sopra menzionata significano che il server MCP deve fornire un'implementazione del server di autorizzazione.

Tuttavia, implementare la funzionalità del server di autorizzazione sul server MCP è una sfida significativa per gli sviluppatori. Da un lato, la maggior parte degli sviluppatori potrebbe non essere familiare con i concetti relativi a OAuth. Dall'altro, ci sono molti dettagli da considerare quando si implementa il server di autorizzazione. Se uno sviluppatore non proviene da un campo correlato, potrebbe introdurre problemi come problemi di sicurezza durante l'implementazione.

Tuttavia, il protocollo stesso non limita il server MCP a implementare solo di per sé la funzionalità del server di autorizzazione. Gli sviluppatori possono completamente reindirizzare o fare da intermediario a questi endpoint relativi all'autorizzazione verso altri server di autorizzazione. Questo non è diverso per il client MCP rispetto all'implementazione della funzionalità del server di autorizzazione stesso del server MCP.

Potresti chiederti, questo approccio dovrebbe utilizzare il metodo di autorizzazione di terze parti delegato menzionato sopra?

Dal mio punto di vista, questo dipende principalmente dal fatto che gli utenti del servizio di autorizzazione di terze parti su cui fai affidamento siano gli stessi degli utenti finali del server MCP. Questo significa che il token di accesso emesso a te dal servizio di autorizzazione di terze parti sarà consumato direttamente dal tuo server MCP.

• Se sì, allora puoi completamente inoltrare le interfacce relative all'autorizzazione nel tuo server MCP ai servizi di autorizzazione di terze parti.

• Se no, allora dovresti usare l'approccio di autorizzazione di terze parti delegato specificato nella specifica. Devi mantenere una relazione di mappatura tra i token di accesso emessi dal server MCP stesso e i token di accesso emessi dai servizi di autorizzazione di terze parti nel server MCP.

Penso che l'approccio di autorizzazione di terze parti delegato specificato nel protocollo sia alquanto vago negli scenari di applicazione pratica. Il protocollo sembra lasciare che terze parti aiutino il server MCP a completare il processo di autorizzazione, ma richiede ancora al server MCP di emettere il proprio token di accesso. Questo in realtà significa che il server MCP porta ancora la responsabilità di emettere i token di accesso come server di autorizzazione, il che non è più conveniente per gli sviluppatori. Penso che probabilmente sia perché gli autori del protocollo hanno considerato che restituire direttamente i token di accesso di terze parti al client MCP porterebbe alcuni problemi di sicurezza (come perdite/abusi, ecc.).

Dalla mia esperienza, lo scenario più adatto per l'autorizzazione di terze parti delegata specificata nel protocollo dovrebbe essere lo scenario di "utenti che autorizzano il server MCP ad accedere a risorse di terze parti". Ad esempio, un server MCP ha bisogno di accedere a un repository GitHub di un utente e distribuire il codice del repository su una piattaforma di distribuzione del codice. In questo caso, l'utente deve autorizzare il server MCP ad accedere al proprio repository GitHub e accedere alla piattaforma di distribuzione del codice.

In questo scenario, il server MCP è un server di autorizzazione per il client MCP, perché gli utenti finali hanno una propria identità nel server MCP. Il server MCP è un client di terze parti per risorse di terze parti (in questo caso, GitHub). Deve ottenere l'autorizzazione dell'utente per accedere alle risorse dell'utente su GitHub. Tra il client MCP e il server MCP, e tra il server MCP e le risorse di terze parti, le identità degli utenti sono separate. Questo rende significativo mantenere una relazione di mappatura tra i token di accesso emessi dal server MCP stesso e i token di accesso emessi dai servizi di autorizzazione di terze parti nel server MCP.

Quindi il protocollo di autorizzazione di terze parti delegato nel protocollo dovrebbe risolvere il problema di "come gli utenti autorizzano il server MCP ad accedere alle risorse degli utenti su server di risorse di terze parti".

Server MCP come server di risorse#

Quando il server MCP agisce come server di risorse, il server MCP deve verificare se la richiesta del client MCP trasporta un token di accesso valido. Il server MCP deciderà se consentire al client MCP di accedere a risorse specifiche basandosi sull'ambito del token di accesso.

Dalla definizione di MCP, la risorsa fornita dal server MCP dovrebbe essere uno strumento per il client MCP da utilizzare. In questo scenario, il server MCP deve solo decidere se fornire agli utenti l'accesso a determinati strumenti.

Ma in scenari del mondo reale, questi strumenti forniti dal server MCP devono anche interagire con il server di risorse del fornitore di servizi del server MCP stesso. A questo punto, il token di accesso ottenuto dal server MCP dalla richiesta del client deve essere utilizzato per accedere al proprio server di risorse. Nella maggior parte dei casi, il server MCP e il server di risorse dietro gli strumenti sono gli stessi sviluppatori. Il server MCP è solo un'interfaccia fornita dalle proprie risorse backend per il client MCP da utilizzare. A questo punto, il server MCP può condividere lo stesso token di accesso emesso da un server di autorizzazione con le risorse backend.

In questo caso, piuttosto che dire che il server MCP è un server di risorse, fornendo strumenti e risorse del proprio servizio, è meglio dire che il server di risorse esistente diventa un server MCP fornendo strumenti per il client MCP da chiamare.

Includere le risorse fornite dal proprio server di risorse nella risorsa fornita dal server MCP è più una considerazione di scenari reali. Ma personalmente preferisco ancora che la risorsa fornita dal server MCP abbia solo strumenti utilizzati dal client MCP, e le risorse da cui dipendono gli strumenti dovrebbero essere risorse ottenute dal server MCP da altri server di risorse (inclusi quelli di prima e terze parti). In questo modo, tutti gli scenari del mondo reale possono essere coperti.

Come funziona l'autorizzazione MCP#

Dopo aver compreso le responsabilità del server MCP come server di autorizzazione e server di risorse, possiamo sapere come funziona specificamente l'autorizzazione MCP:

Registrazione dinamica dei client#

La specifica definisce anche come il server di autorizzazione identifica i client. OAuth 2.1 fornisce un protocollo di registrazione dinamica dei client, consentendo al client MCP di ottenere automaticamente l'ID client OAuth senza intervento manuale dell'utente.

Secondo la specifica, il server MCP dovrebbe supportare il protocollo di registrazione dinamica dei client di OAuth 2.0. In questo modo, il client MCP può registrarsi automaticamente su nuovi server per ottenere l'ID client OAuth. Questo approccio è raccomandato negli scenari MCP principalmente perché:

• Il client MCP non può conoscere in anticipo tutti i possibili server
• La registrazione manuale causerebbe problemi agli utenti
• Rende la connessione con nuovi server senza soluzione di continuità
• I server possono implementare le proprie politiche di registrazione

Tuttavia, da una prospettiva pratica, ho alcune riflessioni sull'applicazione della registrazione dinamica dei client negli scenari MCP:

• Nelle pratiche di servizio OAuth pratiche, il client solitamente corrisponde a un'app specifica. Creare dinamicamente un client potrebbe non aiutare a gestire efficacemente le risorse correlate (utenti, app, ecc.) nei servizi OAuth. I fornitori di servizi OAuth di solito sperano di avere il controllo chiaro sui client collegati, piuttosto che lasciare che qualsiasi client si registri come client a piacimento.
• Molti servizi OAuth non raccomandano o consentono agli utenti di creare dinamicamente client, poiché ciò potrebbe portare ad abusi del servizio. La maggior parte dei fornitori di servizi OAuth maturi (come GitHub, Google, ecc.) richiede agli sviluppatori di registrare manualmente i client tramite il loro console per sviluppatori, e potrebbero anche dover fornire informazioni dettagliate sull'applicazione, URL di callback, ecc.
• La registrazione manuale del client OAuth è in realtà un lavoro una tantum durante lo sviluppo, non qualcosa che ogni utente finale deve fare. Non creerà un grande onere per gli sviluppatori.
• Per il client pubblico (come applicazioni native, applicazioni a pagina singola, ecc.), abbiamo modi più sicuri per implementare il flusso OAuth senza registrazione dinamica. L'ID client combinato con PKCE (Proof Key for Code Exchange) può fornire un flusso OAuth abbastanza sicuro per il client pubblico senza creare dinamicamente un client.
• Anche se il protocollo indica che l'uso della registrazione dinamica dei client può evitare che i client debbano conoscere l'ID client in anticipo, in realtà, il client MCP deve sempre conoscere l'indirizzo del server MCP remoto in anticipo. Se è così, specificare l'ID client mentre si passa l'indirizzo del server MCP remoto non porterà molto, se non nessun problema. Oppure, possiamo anche creare una convenzione per il client MCP per richiedere l'ID client al server MCP, il che non è un compito difficile.

Anche se la registrazione dinamica dei client fornisce flessibilità per l'ecosistema MCP in teoria, nell'implementazione pratica, potremmo dover considerare se abbiamo davvero bisogno di questo meccanismo di registrazione dinamica. Per la maggior parte dei fornitori di servizi, creare manualmente e gestire il client OAuth potrebbe essere un modo più controllabile e sicuro.

Sommario#

Questo articolo analizza approfonditamente la filosofia di progettazione e le sfide di implementazione della specifica di autorizzazione MCP. Come un framework di autorizzazione basato su OAuth 2.1, questa specifica mira a risolvere il problema chiave di come il server MCP remoto accede alle risorse degli utenti per conto degli utenti.

Attraverso una discussione dettagliata dei doppi ruoli del server MCP come server di autorizzazione e server di risorse, così come i pro ei contro di meccanismi come la registrazione dinamica dei client e l'autorizzazione delegata di terze parti, questo articolo fornisce pensieri e suggerimenti basati sull'esperienza personale nell'implementazione di Authenticator.

Vale la pena notare che la specifica di autorizzazione MCP è ancora in evoluzione. Come membro del team Logto, continueremo a prestare attenzione agli ultimi sviluppi di questa specifica e a ottimizzare continuamente le nostre soluzioni di implementazione nella pratica per contribuire all'interazione sicura tra modelli di IA e servizi esterni.