Autentificarea este cel mai critic strat de securitate pentru serverele MCP la distanță. Aflați de ce OAuth 2.1 cu OIDC este obligatoriu, cum delegarea token-urilor previne atacul Deputatului Confuz și de ce transmiterea token-urilor este unul dintre cele mai periculoase modele în integrările AI.
Autentificarea este porțilerul care determină dacă capacitățile puternice ale unui server MCP sunt disponibile utilizatorilor legitimi sau atacatorilor. Dacă greșiți, fiecare alt control de securitate devine irelevant — un server MCP neautentificat sau slab autentificat cu acces la email, fișiere și baze de date este o vulnerabilitate critică indiferent de cât de bine ați fortificat tot restul.
Ghidul Proiectului de Securitate OWASP GenAI identifică autentificarea și autorizarea ca fiind unul dintre cele opt domenii de securitate de bază pentru serverele MCP, cu cerințe specifice care depășesc ceea ce majoritatea dezvoltatorilor implementează în mod implicit. Această postare explică de ce există aceste cerințe și cum să le implementați corect.
Serverele MCP se confruntă cu un peisaj de autentificare mai complex decât serviciile tradiționale deoarece mediază între mai mulți principali:
Fiecare dintre aceste relații necesită propriile controale de autentificare și autorizare. O slăbiciune în orice verigă poate fi exploatată pentru a ocoli celelalte.
Pentru serverele MCP la distanță — cele accesate prin rețea mai degrabă decât prin STDIO local sau socket-uri Unix — ghidul OWASP GenAI este neambiguu: OAuth 2.1 cu OIDC este obligatoriu, nu opțional.
Această cerință există deoarece:
OAuth 2.1 oferă control explicit al domeniilor. Fiecare token de acces declară exact ce resurse și acțiuni autorizează. Un server MCP poate verifica la momentul invocării instrumentului că token-ul prezentat are domeniul specific necesar pentru acea acțiune — nu doar că utilizatorul este autentificat, ci că este autorizat pentru această operațiune specifică.
OIDC oferă identitate criptografică. OpenID Connect adaugă afirmații de identitate (token-ul ID) pe care serverul MCP le poate verifica fără a face round-trip către furnizorul de identitate. Serverul validează iss (emitent), aud (audiență), exp (expirare) și semnătura la fiecare cerere.
Token-urile OAuth 2.1 sunt de scurtă durată prin design. Specificația OAuth modernă (care consolidează și înlocuiește cele mai bune practici OAuth 2.0) pune accent pe token-uri de acces de scurtă durată care trebuie reîmprospătate regulat. Acest lucru limitează fereastra de daune dacă un token este compromis.
Nu validați token-urile doar la stabilirea sesiunii. Validați la fiecare invocare a instrumentului:
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
Nu cache-uiți niciodată rezultatele validării între cereri. Un token care a fost valid la începutul sesiunii poate fi revocat în mijlocul sesiunii.
În medii în care clienții MCP se schimbă frecvent (de exemplu, diferiți asistenți AI care se conectează la același server), cheile API statice sau secretele pre-partajate sunt insuficiente. Utilizați înregistrarea dinamică a clienților cu OAuth 2.1 sau OIDC pentru a verifica identitatea clientului la momentul conectării. Listele de permisiuni, politicile de conexiune codificate fix sau TLS mutual (mTLS) sunt adecvate pentru relații statice cunoscute între clienți și servere specifice.
Începe perioada de probă gratuită astăzi și vezi rezultate în câteva zile.
Deputatul Confuz este o vulnerabilitate clasică de autorizare cu o manifestare deosebit de periculoasă în arhitecturile MCP. Atacul exploatează ambiguitatea cu a cui autoritate acționează un server MCP.
Luați în considerare acest scenariul:
Când Alice cere asistentului AI să “rezume dosarul meu de proiect”, serverul folosește token-ul lui Alice pentru a accesa fișierele ei — comportament corect. Dar dacă un atacator păcălește serverul să facă o cerere folosind propriile sale credențiale de serviciu (poate printr-un atac de otrăvire a instrumentelor sau injecție indirectă de prompt), permisiunile ridicate ale serverului sunt folosite pentru a accesa fișiere pe care Alice nu este autorizată să le vadă.
Serverul este “deputatul confuz” — a fost păcălit să folosească autoritatea sa în numele cuiva care nu are acea autoritate, acționând ca un proxy pentru escaladarea privilegiilor.
Multe implementări MCP transmit token-ul clientului către API-uri downstream pentru simplitate. Acest lucru pare intuitiv — token-ul utilizatorului reprezintă permisiunile utilizatorului, deci utilizarea lui pentru toate apelurile downstream menține controlul corect al accesului.
Problema: API-urile downstream care recunosc serverul MCP ca un intermediar de încredere pot acorda cereri folosind nivelul de identitate al serverului, nu nivelul token-ului utilizatorului transmis. Și dacă serverul MCP acționează vreodată din proprie inițiativă — prin luarea de decizii AI pe care utilizatorul nu le-a solicitat explicit — poate folosi propriile credențiale în loc de token-ul utilizatorului.
Transmiterea token-urilor utilizatorilor de asemenea:
În loc să transmită token-urile clienților, serverul MCP ar trebui să obțină propriile token-uri pentru accesul la servicii downstream folosind fluxul On-Behalf-Of (OBO) al OAuth:
Utilizatorul se autentifică la clientul MCP → clientul obține token de acces utilizator
Clientul MCP prezintă token-ul utilizatorului la serverul MCP
Serverul MCP schimbă token-ul utilizatorului cu un token de server prin fluxul OBO:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
Serverul MCP folosește propriul său token OBO pentru apelurile downstream
Token-ul OBO:
Ghidul OWASP GenAI face o recomandare specifică: emiteți token-uri de acces cu durate de viață măsurate în minute, nu în ore. Acest lucru se aplică atât token-urilor pe care serverul MCP le acceptă de la clienți, cât și token-urilor pe care le obține pentru accesul la servicii downstream.
Un token de acces furat este valid pentru întreaga sa durată de viață indiferent dacă utilizatorul legitim s-a deconectat, și-a schimbat parola sau și-a revocat sesiunea. Un token de 24 de ore furat la începutul unei sesiuni oferă unui atacator 24 de ore de acces persistent. Un token de 5 minute furat în mijlocul sesiunii oferă cel mult 5 minute.
Token-urile de scurtă durată impun de asemenea evenimente regulate de re-autentificare, care oferă oportunități de a:
Fiecare token ar trebui să poarte doar domeniile necesare pentru operațiunea specifică care se efectuează. Nu emiteți un token cu domeniul read:files write:files delete:files când apelul curent al instrumentului necesită doar read:files. Acest lucru limitează daunele dacă token-ul este interceptat sau modelul este manipulat în apeluri neașteptate ale instrumentelor.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Mapează instrumentul la domeniile minime necesare
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # durată de viață de 5 minute
)
Primește cele mai recente sfaturi, tendințe și oferte gratuit.
O greșeală comună este utilizarea ID-urilor de sesiune ca proxy-uri de autorizare: dacă o cerere poartă un ID de sesiune valid, serverul presupune că este autorizată. Acest lucru confundă gestionarea stării cu verificarea identității.
Modelul corect: ID-urile de sesiune gestionează starea conversațională. Autorizarea este verificată independent la fiecare cerere prin validarea afirmațiilor token-ului OAuth. Chiar și o cerere care poartă un ID de sesiune valid trebuie să prezinte un token OAuth valid, neexpirat, cu domeniu adecvat înainte ca orice invocare a instrumentului să fie permisă.
Acest lucru contează deoarece ID-urile de sesiune pot fi furate, ghicite sau redate în moduri în care token-urile OAuth — care poartă garanții de integritate criptografică — nu pot.
În loc să implementeze verificări de autorizare împrăștiate în handlere individuale de instrumente, ghidul OWASP GenAI recomandă o gateway centralizată de politici care:
Centralizarea asigură că politicile sunt aplicate în mod consecvent pe toate instrumentele și agenții. O verificare de autorizare specifică instrumentului poate fi uitată sau ocolită în timpul dezvoltării; o verificare gateway nu poate.
Pentru serverele MCP la distanță, bara minimă de securitate a autentificării este:
OAuth 2.1 este necesar pentru serverele MCP la distanță deoarece oferă autorizare delegată cu control explicit al domeniilor de acces, token-uri de scurtă durată, verificare criptografică și afirmații de identitate standardizate (prin OIDC). Metodele mai simple precum cheile API sau cookie-urile de sesiune nu au granularitatea domeniilor necesară pentru a implementa accesul cu privilegii minime, nu oferă garanții de identitate criptografică și sunt dificil de revocat granular când o sesiune se încheie.
Deputatul Confuz este un atac de escaladare a privilegiilor în care serverul MCP este păcălit să folosească propriile sale privilegii (mai înalte) pentru a efectua acțiuni pe care utilizatorul solicitant nu este autorizat să le efectueze. Apare când se folosește transmiterea token-urilor — serverul transmite token-ul unui utilizator către API-uri downstream, ceea ce poate acorda utilizatorului acces pe care nu ar trebui să îl aibă pe baza statutului de încredere al serverului. Soluția este utilizarea fluxurilor de token-uri On-Behalf-Of unde token-urile sunt emise explicit pentru domeniul de acces specific al serverului MCP.
Transmiterea token-urilor înseamnă că serverul MCP transmite token-ul de autentificare al clientului direct către API-uri downstream, în loc să folosească propriile sale credențiale emise de server. Acest lucru este periculos deoarece: (1) întrerupe pistele de audit — sistemele downstream văd token-ul utilizatorului, nu serverul MCP, făcând imposibilă atribuirea acțiunilor către server; (2) ocolește propriile politici de acces ale serverului MCP; (3) creează o vulnerabilitate de Deputat Confuz dacă API-ul downstream are mai multă încredere în identitatea serverului MCP decât în cea a utilizatorului; și (4) dacă serverul MCP este compromis, atacatorul obține acces la token-urile utilizatorilor transmise pentru toate serviciile downstream conectate.
Ghidul OWASP GenAI recomandă token-uri cu durate de viață măsurate în minute, nu în ore sau zile. Duratele mai scurte ale token-urilor limitează fereastra de exploatare dacă un token este furat sau o sesiune este deturnată. Fiecare invocare a instrumentului ar trebui să revalideze semnătura, audiența și expirarea token-ului — nu să se bazeze pe validarea cache-uită de la începutul sesiunii.
Arshia este Inginer de Fluxuri AI la FlowHunt. Cu o pregătire în informatică și o pasiune pentru inteligența artificială, el este specializat în crearea de fluxuri eficiente care integrează instrumente AI în sarcinile de zi cu zi, sporind productivitatea și creativitatea.
Echipa noastră de securitate evaluează configurațiile de autentificare MCP, gestionarea token-urilor și fluxurile de autorizare conform standardelor OWASP GenAI. Identificați lacunele înainte ca atacatorii să o facă.
Serverele MCP expun o suprafață de atac unică care combină riscurile tradiționale ale API-urilor cu amenințări specifice AI. Învață cele 6 vulnerabilități criti...
Serverul MCP pentru Authenticator App permite agenților AI să acceseze în siguranță coduri 2FA și parole, simplificând procesele automate de autentificare și ge...
Serverul Auth0 MCP face legătura între asistenții AI și serviciile de autentificare și identitate ale Auth0. Integrați capabilități de autentificare utilizatori...