L’autenticazione è il livello di sicurezza più critico per i server MCP remoti. Scopri perché OAuth 2.1 con OIDC è obbligatorio, come la delega dei token previene l’attacco Confused Deputy e perché il token passthrough è uno dei pattern più pericolosi nelle integrazioni AI.
L’autenticazione è il guardiano che determina se le potenti capacità di un server MCP sono disponibili per utenti legittimi o per attaccanti. Se sbagli, ogni altro controllo di sicurezza diventa irrilevante — un server MCP non autenticato o mal autenticato con accesso a email, file e database è una vulnerabilità critica indipendentemente da quanto bene hai rafforzato tutto il resto.
La guida del Progetto di Sicurezza OWASP GenAI identifica autenticazione e autorizzazione come uno degli otto domini di sicurezza fondamentali per i server MCP, con requisiti specifici che vanno oltre ciò che la maggior parte degli sviluppatori implementa per impostazione predefinita. Questo post spiega perché esistono questi requisiti e come implementarli correttamente.
I server MCP affrontano un panorama di autenticazione più complesso rispetto ai servizi tradizionali perché mediano tra più principali:
Ciascuna di queste relazioni richiede i propri controlli di autenticazione e autorizzazione. Una debolezza in qualsiasi anello può essere sfruttata per bypassare gli altri.
Per i server MCP remoti — quelli accessibili tramite rete anziché attraverso STDIO locale o socket Unix — la guida OWASP GenAI è inequivocabile: OAuth 2.1 con OIDC è obbligatorio, non facoltativo.
Questo requisito esiste perché:
OAuth 2.1 fornisce controllo esplicito degli scope. Ogni token di accesso dichiara esattamente quali risorse e azioni autorizza. Un server MCP può verificare al momento dell’invocazione dello strumento che il token presentato ha lo scope specifico necessario per quell’azione — non solo che l’utente è autenticato, ma che è autorizzato per questa operazione specifica.
OIDC fornisce identità crittografica. OpenID Connect aggiunge asserzioni di identità (il token ID) che il server MCP può verificare senza fare un round-trip al provider di identità. Il server valida iss (issuer), aud (audience), exp (expiry) e la firma su ogni richiesta.
I token OAuth 2.1 sono di breve durata per design. La specifica OAuth moderna (che consolida e sostituisce le best practice di OAuth 2.0) enfatizza token di accesso di breve durata che devono essere regolarmente rinnovati. Questo limita la finestra di danno se un token viene compromesso.
Non validare i token solo all’instaurazione della sessione. Valida su ogni invocazione di strumento:
def validate_token(token: str, required_scope: str) -> TokenClaims:
claims = jwt.decode(
token,
key=get_public_key(claims_preview['kid']),
algorithms=["RS256", "ES256"]
)
assert claims['iss'] == EXPECTED_ISSUER
assert EXPECTED_AUDIENCE in claims['aud']
assert claims['exp'] > time.time()
assert required_scope in claims['scope'].split()
return claims
Non memorizzare mai i risultati della validazione tra le richieste. Un token che era valido all’inizio della sessione potrebbe essere revocato a metà sessione.
In ambienti dove i client MCP cambiano frequentemente (ad es., diversi assistenti AI che si connettono allo stesso server), chiavi API statiche o segreti pre-condivisi sono insufficienti. Usa la registrazione dinamica del client con OAuth 2.1 o OIDC per verificare l’identità del client al momento della connessione. Le allowlist, le policy di connessione hardcoded o il mutual TLS (mTLS) sono appropriati per relazioni statiche note tra client e server specifici.
Inizia oggi la tua prova gratuita e vedi i risultati in pochi giorni.
Il Confused Deputy è una vulnerabilità di autorizzazione classica con una manifestazione particolarmente pericolosa nelle architetture MCP. L’attacco sfrutta l’ambiguità di con quale autorità sta agendo un server MCP.
Considera questo scenario:
Quando Alice chiede all’assistente AI di “riassumere la mia cartella di progetto”, il server usa il token di Alice per accedere ai suoi file — comportamento corretto. Ma se un attaccante inganna il server nel fare una richiesta usando le proprie credenziali di servizio (forse attraverso un attacco di tool poisoning o iniezione di prompt indiretta), i permessi elevati del server vengono usati per accedere a file che Alice non è autorizzata a vedere.
Il server è il “deputy confuso” — è stato ingannato nell’usare la propria autorità per conto di qualcuno che non ha quell’autorità, agendo come proxy per l’escalation dei privilegi.
Molte implementazioni MCP inoltrano il token del client alle API downstream per semplicità. Questo sembra intuitivo — il token dell’utente rappresenta i permessi dell’utente, quindi usarlo per tutte le chiamate downstream mantiene il corretto controllo degli accessi.
Il problema: le API downstream che riconoscono il server MCP come intermediario fidato potrebbero concedere richieste usando il livello di identità del server, non il livello del token utente inoltrato. E se il server MCP agisce mai di propria iniziativa — attraverso il processo decisionale dell’AI che l’utente non ha esplicitamente richiesto — potrebbe usare le proprie credenziali anziché il token dell’utente.
L’inoltro dei token utente inoltre:
Invece di inoltrare i token del client, il server MCP dovrebbe ottenere i propri token per l’accesso ai servizi downstream usando il flusso On-Behalf-Of (OBO) di OAuth:
L'utente si autentica al client MCP → il client ottiene il token di accesso utente
Il client MCP presenta il token utente al server MCP
Il server MCP scambia il token utente per un token server tramite flusso OBO:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
Il server MCP usa il proprio token OBO per le chiamate downstream
Il token OBO:
La guida OWASP GenAI fa una raccomandazione specifica: emettere token di accesso con durate misurate in minuti, non ore. Questo si applica sia ai token che il server MCP accetta dai client sia ai token che ottiene per l’accesso ai servizi downstream.
Un token di accesso rubato è valido per tutta la sua durata indipendentemente dal fatto che l’utente legittimo si sia disconnesso, abbia cambiato la password o abbia revocato la sessione. Un token di 24 ore rubato all’inizio di una sessione dà a un attaccante 24 ore di accesso persistente. Un token di 5 minuti rubato a metà sessione dà al massimo 5 minuti.
I token di breve durata impongono anche eventi di ri-autenticazione regolari, che forniscono opportunità per:
Ogni token dovrebbe portare solo gli scope necessari per l’operazione specifica che viene eseguita. Non emettere un token con scope read:files write:files delete:files quando la chiamata allo strumento corrente necessita solo di read:files. Questo limita il danno se il token viene intercettato o il modello viene manipolato in chiamate di strumenti inaspettate.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Mappa lo strumento agli scope minimi richiesti
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # durata di 5 minuti
)
Ricevi gratuitamente gli ultimi consigli, tendenze e offerte.
Un errore comune è usare gli ID di sessione come proxy di autorizzazione: se una richiesta porta un ID di sessione valido, il server assume che sia autorizzata. Questo confonde la gestione dello stato con la verifica dell’identità.
Il modello corretto: gli ID di sessione gestiscono lo stato conversazionale. L’autorizzazione viene verificata indipendentemente su ogni richiesta validando i claim del token OAuth. Anche una richiesta che porta un ID di sessione valido deve presentare un token OAuth valido, non scaduto e con scope appropriato prima che qualsiasi invocazione di strumento sia permessa.
Questo è importante perché gli ID di sessione possono essere rubati, indovinati o riprodotti in modi che i token OAuth — che portano garanzie di integrità crittografica — non possono.
Anziché implementare controlli di autorizzazione sparsi in singoli gestori di strumenti, la guida OWASP GenAI raccomanda un gateway di policy centralizzato che:
La centralizzazione garantisce che le policy siano applicate in modo coerente su tutti gli strumenti e agenti. Un controllo di autorizzazione specifico dello strumento può essere dimenticato o bypassato durante lo sviluppo; un controllo del gateway non può.
Per i server MCP remoti, il livello minimo di sicurezza dell’autenticazione è:
OAuth 2.1 è richiesto per i server MCP remoti perché fornisce autorizzazione delegata con controllo esplicito degli scope, token di breve durata, verifica crittografica e asserzioni di identità standardizzate (tramite OIDC). Metodi più semplici come chiavi API o cookie di sessione mancano della granularità degli scope necessaria per implementare l'accesso con privilegi minimi, non forniscono garanzie di identità crittografiche e sono difficili da revocare in modo granulare quando una sessione termina.
Il Confused Deputy è un attacco di escalation dei privilegi in cui il server MCP viene ingannato nell'usare i propri privilegi (superiori) per eseguire azioni che l'utente richiedente non è autorizzato a eseguire. Si verifica quando viene utilizzato il token passthrough — il server inoltra il token di un utente alle API downstream, che potrebbero concedere all'utente accesso che non dovrebbe avere in base allo status fidato del server. La soluzione è utilizzare flussi di token On-Behalf-Of in cui i token vengono esplicitamente emessi per lo scope di accesso specifico del server MCP.
Il token passthrough significa che il server MCP inoltra direttamente il token di autenticazione del client alle API downstream, anziché utilizzare le proprie credenziali emesse dal server. Questo è pericoloso perché: (1) interrompe le tracce di audit — i sistemi downstream vedono il token utente, non il server MCP, rendendo impossibile attribuire le azioni al server; (2) bypassa le policy di accesso proprie del server MCP; (3) crea una vulnerabilità Confused Deputy se l'API downstream si fida dell'identità del server MCP più di quella dell'utente; e (4) se il server MCP è compromesso, l'attaccante ottiene accesso ai token utente inoltrati per tutti i servizi downstream connessi.
La guida OWASP GenAI raccomanda token con durate misurate in minuti, non ore o giorni. Durate di token più brevi limitano la finestra di sfruttamento se un token viene rubato o una sessione viene dirottata. Ogni invocazione di strumento dovrebbe rivalidare la firma del token, l'audience e la scadenza — non affidarsi alla validazione memorizzata dall'inizio della sessione.
Arshia è una AI Workflow Engineer presso FlowHunt. Con una formazione in informatica e una passione per l'IA, è specializzata nella creazione di workflow efficienti che integrano strumenti di intelligenza artificiale nelle attività quotidiane, migliorando produttività e creatività.
Il nostro team di sicurezza valuta le configurazioni di autenticazione MCP, la gestione dei token e i flussi di autorizzazione secondo gli standard OWASP GenAI. Identifica le lacune prima che lo facciano gli attaccanti.
I server MCP espongono una superficie di attacco unica che combina i rischi tradizionali delle API con le minacce specifiche dell'AI. Scopri le 6 vulnerabilità ...
Il Server MCP per Authenticator App consente agli agenti AI di accedere in modo sicuro a codici 2FA e password, semplificando i processi di login automatizzati ...
L'Attestable MCP Server porta l'attestazione remota e il calcolo confidenziale nei workflow FlowHunt, consentendo agli agenti AI e ai client di verificare l'int...