Authenticatie is de meest kritieke beveiligingslaag voor externe MCP-servers. Leer waarom OAuth 2.1 met OIDC verplicht is, hoe token delegatie de Confused Deputy aanval voorkomt, en waarom token passthrough een van de gevaarlijkste patronen is in AI-integraties.
Authenticatie is de poortwachter die bepaalt of de krachtige mogelijkheden van een MCP-server beschikbaar zijn voor legitieme gebruikers of voor aanvallers. Als u het verkeerd doet, wordt elke andere beveiligingscontrole irrelevant — een niet-geauthenticeerde of slecht geauthenticeerde MCP-server met toegang tot e-mail, bestanden en databases is een kritieke kwetsbaarheid, ongeacht hoe goed u al het andere hebt verhard.
De gids van het OWASP GenAI Security Project identificeert authenticatie en autorisatie als een van de acht kernbeveiligingsdomeinen voor MCP-servers, met specifieke vereisten die verder gaan dan wat de meeste ontwikkelaars standaard implementeren. Dit artikel legt uit waarom die vereisten bestaan en hoe u ze correct implementeert.
MCP-servers worden geconfronteerd met een complexer authenticatielandschap dan traditionele diensten omdat ze bemiddelen tussen meerdere principals:
Elk van deze relaties vereist zijn eigen authenticatie- en autorisatiecontroles. Een zwakte in een willekeurige schakel kan worden uitgebuit om de anderen te omzeilen.
Voor externe MCP-servers — die via een netwerk worden benaderd in plaats van via lokale STDIO of Unix-sockets — is de OWASP GenAI-gids ondubbelzinnig: OAuth 2.1 met OIDC is verplicht, niet optioneel.
Deze vereiste bestaat omdat:
OAuth 2.1 biedt expliciete scope-controle. Elk toegangstoken declareert precies welke bronnen en acties het autoriseert. Een MCP-server kan op het moment van tool-aanroep verifiëren dat het gepresenteerde token de specifieke scope heeft die nodig is voor die actie — niet alleen dat de gebruiker is geauthenticeerd, maar dat ze geautoriseerd zijn voor deze specifieke operatie.
OIDC biedt cryptografische identiteit. OpenID Connect voegt identiteitsbeweringen toe (het ID-token) die de MCP-server kan verifiëren zonder round-trip naar de identiteitsprovider. De server valideert de iss (issuer), aud (audience), exp (expiry) en handtekening bij elk verzoek.
OAuth 2.1 tokens zijn van nature kortlevend. De moderne OAuth-specificatie (die OAuth 2.0 best practices consolideert en vervangt) benadrukt kortlevende toegangstokens die regelmatig moeten worden vernieuwd. Dit beperkt het schadelijke venster als een token wordt gecompromitteerd.
Valideer tokens niet alleen bij het opzetten van de sessie. Valideer bij elke tool-aanroep:
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
Cache validatieresultaten nooit over verzoeken heen. Een token dat geldig was bij het starten van de sessie kan halverwege de sessie worden ingetrokken.
In omgevingen waar MCP-clients frequent veranderen (bijv. verschillende AI-assistenten die verbinding maken met dezelfde server), zijn statische API-sleutels of vooraf gedeelde geheimen onvoldoende. Gebruik dynamische clientregistratie met OAuth 2.1 of OIDC om de client-identiteit te verifiëren op het moment van verbinding. Allowlists, hardcoded verbindingsbeleid of wederzijdse TLS (mTLS) zijn geschikt voor bekende statische relaties tussen specifieke clients en servers.
Start vandaag uw gratis proefperiode en zie binnen enkele dagen resultaten.
De Confused Deputy is een klassieke autorisatiekwetsbaarheid met een bijzonder gevaarlijke manifestatie in MCP-architecturen. De aanval exploiteert de dubbelzinnigheid van wiens autoriteit een MCP-server gebruikt.
Beschouw dit scenario:
Wanneer Alice de AI-assistent vraagt om “mijn projectmap samen te vatten,” gebruikt de server Alice’s token om toegang te krijgen tot haar bestanden — correct gedrag. Maar als een aanvaller de server misleidt om een verzoek te doen met zijn eigen servicecredentials (misschien via een tool poisoning-aanval of indirecte prompt injection), worden de verhoogde rechten van de server gebruikt om toegang te krijgen tot bestanden waarvoor Alice niet geautoriseerd is.
De server is de “confused deputy” — hij is misleid om zijn autoriteit te gebruiken namens iemand die die autoriteit niet heeft, en fungeert als proxy voor privilege escalatie.
Veel MCP-implementaties sturen het token van de client door naar downstream API’s voor de eenvoud. Dit lijkt intuïtief — het token van de gebruiker vertegenwoordigt de rechten van de gebruiker, dus het gebruik ervan voor alle downstream aanroepen handhaaft correcte toegangscontrole.
Het probleem: downstream API’s die de MCP-server herkennen als een vertrouwde tussenpersoon kunnen verzoeken goedkeuren op basis van het identiteitsniveau van de server, niet op het niveau van het doorgestuurde gebruikerstoken. En als de MCP-server ooit op eigen initiatief handelt — door AI-besluitvorming die de gebruiker niet expliciet heeft aangevraagd — kan het zijn eigen credentials gebruiken in plaats van het token van de gebruiker.
Het doorsturen van gebruikerstokens:
In plaats van clienttokens door te sturen, moet de MCP-server zijn eigen tokens verkrijgen voor downstream service-toegang met behulp van OAuth’s On-Behalf-Of (OBO) flow:
Gebruiker authenticeert bij MCP-client → client krijgt gebruikerstoegangstoken
MCP-client presenteert gebruikerstoken aan MCP-server
MCP-server wisselt gebruikerstoken in voor een servertoken via OBO flow:
POST /token
grant_type=urn:ietf:params:oauth:grant-type:jwt-bearer
assertion=<user_access_token>
scope=<minimum_required_scope>
MCP-server gebruikt zijn eigen OBO-token voor downstream aanroepen
Het OBO-token:
De OWASP GenAI-gids doet een specifieke aanbeveling: geef toegangstokens uit met levensduren gemeten in minuten, niet uren. Dit geldt zowel voor de tokens die de MCP-server accepteert van clients als voor de tokens die het verkrijgt voor downstream service-toegang.
Een gestolen toegangstoken is geldig voor zijn volledige levensduur, ongeacht of de legitieme gebruiker is uitgelogd, zijn wachtwoord heeft gewijzigd of zijn sessie heeft ingetrokken. Een 24-uurs token dat aan het begin van een sessie wordt gestolen, geeft een aanvaller 24 uur persistente toegang. Een 5-minuten token dat halverwege de sessie wordt gestolen, geeft maximaal 5 minuten.
Kortlevende tokens dwingen ook regelmatige herauthenticatiegebeurtenissen af, die mogelijkheden bieden om:
Elk token moet alleen de scopes bevatten die nodig zijn voor de specifieke operatie die wordt uitgevoerd. Geef geen token uit met read:files write:files delete:files scope wanneer de huidige tool-aanroep alleen read:files nodig heeft. Dit beperkt de schade als het token wordt onderschept of het model wordt gemanipuleerd tot onverwachte tool-aanroepen.
def get_tool_token(user_id: str, tool_name: str) -> str:
# Map tool naar minimaal vereiste scopes
required_scopes = TOOL_SCOPE_MAP[tool_name]
return oauth_client.get_token(
subject=user_id,
scopes=required_scopes,
lifetime_seconds=300 # 5 minuten levensduur
)
Ontvang gratis de nieuwste tips, trends en aanbiedingen.
Een veelgemaakte fout is het gebruik van sessie-ID’s als autorisatieproxies: als een verzoek een geldige sessie-ID bevat, gaat de server ervan uit dat het geautoriseerd is. Dit vermengt statusbeheer met identiteitsverificatie.
Het juiste model: sessie-ID’s beheren conversatiestatus. Autorisatie wordt onafhankelijk geverifieerd bij elk verzoek door de claims van het OAuth-token te valideren. Zelfs een verzoek met een geldige sessie-ID moet een geldig, niet-verlopen, correct gescoped OAuth-token presenteren voordat een tool-aanroep is toegestaan.
Dit is belangrijk omdat sessie-ID’s kunnen worden gestolen, geraden of opnieuw afgespeeld op manieren waarop OAuth-tokens — die cryptografische integriteitsgaranties bevatten — dat niet kunnen.
In plaats van autorisatiecontroles verspreid over individuele tool-handlers te implementeren, beveelt de OWASP GenAI-gids een gecentraliseerde beleidsgateway aan die:
Centralisatie zorgt ervoor dat beleid consistent wordt toegepast over alle tools en agents. Een tool-specifieke autorisatiecontrole kan tijdens ontwikkeling worden vergeten of omzeild; een gateway-controle niet.
Voor externe MCP-servers is de minimale authenticatiebeveiligingsdrempel:
OAuth 2.1 is vereist voor externe MCP-servers omdat het gedelegeerde autorisatie biedt met expliciete scope-controle, kortlevende tokens, cryptografische verificatie en gestandaardiseerde identiteitsbeweringen (via OIDC). Eenvoudigere methoden zoals API-sleutels of sessiecookies missen de scope-granulariteit die nodig is om toegang met minimale privileges te implementeren, bieden geen cryptografische identiteitsgaranties en zijn moeilijk granulaar in te trekken wanneer een sessie eindigt.
De Confused Deputy is een privilege escalatie-aanval waarbij de MCP-server wordt misleid om zijn eigen (hogere) privileges te gebruiken om acties uit te voeren waarvoor de aanvragende gebruiker niet geautoriseerd is. Het treedt op wanneer token passthrough wordt gebruikt — de server stuurt het token van een gebruiker door naar downstream API's, wat de gebruiker mogelijk toegang kan geven die ze niet zouden moeten hebben op basis van de vertrouwde status van de server. De oplossing is het gebruik van On-Behalf-Of token flows waarbij tokens expliciet worden uitgegeven voor de specifieke toegangsscope van de MCP-server.
Token passthrough betekent dat de MCP-server het authenticatietoken van de client rechtstreeks doorstuurt naar downstream API's, in plaats van zijn eigen door de server uitgegeven credentials te gebruiken. Dit is gevaarlijk omdat: (1) het audittrails doorbreekt — downstream systemen zien het gebruikerstoken, niet de MCP-server, waardoor het onmogelijk is om acties toe te schrijven aan de server; (2) het het eigen toegangsbeleid van de MCP-server omzeilt; (3) het een Confused Deputy kwetsbaarheid creëert als de downstream API de identiteit van de MCP-server meer vertrouwt dan die van de gebruiker; en (4) als de MCP-server gecompromitteerd wordt, krijgt de aanvaller toegang tot doorgestuurde gebruikerstokens voor alle verbonden downstream services.
De OWASP GenAI-gids beveelt tokens aan met levensduren gemeten in minuten, niet uren of dagen. Kortere tokenlevensduren beperken het exploitatievenster als een token wordt gestolen of een sessie wordt gekaapt. Elke tool-aanroep moet de handtekening, het publiek en de vervaldatum van het token opnieuw valideren — niet vertrouwen op gecachte validatie vanaf de start van de sessie.
Arshia is een AI Workflow Engineer bij FlowHunt. Met een achtergrond in computerwetenschappen en een passie voor AI, specialiseert zij zich in het creëren van efficiënte workflows die AI-tools integreren in dagelijkse taken, waardoor productiviteit en creativiteit worden verhoogd.
Ons beveiligingsteam beoordeelt MCP authenticatieconfiguraties, token-afhandeling en autorisatiestromen volgens de OWASP GenAI-normen. Identificeer hiaten voordat aanvallers dat doen.
MCP servers bieden een uniek aanvalsoppervlak dat traditionele API-risico's combineert met AI-specifieke bedreigingen. Leer de 6 kritieke kwetsbaarheden geïdent...
De Authenticator App MCP Server stelt AI-agenten in staat om veilig 2FA-codes en wachtwoorden te benaderen, waardoor geautomatiseerde aanmeldprocessen en wachtw...
De Auth0 MCP Server verbindt AI-assistenten met de authenticatie- en identiteitsdiensten van Auth0. Integreer realtime gebruikersauthenticatie, autorisatie en i...