MCP-authenticatie uitgelegd: hoe het werkt en waarom het belangrijk is

MCP-authenticatie en -autorisatie zijn niet altijd zo veilig geweest als vandaag de dag. Toen MCP voor het eerst werd uitgerold, vond authenticatie meestal plaats via API-sleutels. Deze werden vaak opgenomen in een configuratiebestand of als omgevingsvariabelen, waardoor statische, gedeelde en niet-afgebakende toegang mogelijk was. Als deze sleutel lekte, kreeg een kwaadwillende gebruiker volledige toegang, zonder dat er een manier was om te traceren of te controleren wat er werd gedaan.

De MCP-specificatie is snel geëvolueerd om dit aan te pakken:

• Maart 2025: OAuth 2.1 werd gedefinieerd als de standaard voor het authenticeren van een applicatie of gebruiker bij een API.
• Juni 2025: MCP-servers werden opnieuw gedefinieerd als OAuth-resource-servers, en de mogelijkheid om tokens uit te geven verhuisde naar externe identity providers.
• November 2025: PKCE werd verplicht voor alle client-side applicaties, en CIMD werd gedefinieerd als een manier om elke client-instantie uniek te identificeren.

In minder dan een jaar tijd is de MCP-authenticatiemethode overgegaan van statische secrets naar een model dat consistent is met moderne enterprise-identiteitssystemen.

In deze gids leest u wat MCP-authenticatie is, hoe het werkt, wat de mogelijke benaderingen zijn om het te implementeren, waar implementaties de fout in gaan en hoe u het op schaal correct kunt implementeren.

Wat is MCP-authenticatie?

MCP-authenticatie is het proces waarmee een MCP-server de identiteit van een aanvrager verifieert voordat een tool wordt uitgevoerd.

Zonder ingestelde MCP-authenticatie zou elke MCP-client die een MCP-server kan bereiken, de tools daarvan kunnen aanroepen, ongeacht de identiteit, rol of intentie van die client. Als de aangeroepen tools een verbinding tot stand brengen met kritieke externe systemen zoals CRM's, databases of cloudservices, zou dat een onbeperkte toegangsweg creëren tot gevoelige productiegegevens.

Dit is geen theoretisch risico. Een CVSS 9.6-kwetsbaarheid in het package mcp-remote stelde kwaadwillende MCP-servers in staat om de OAuth-flow binnen het package te misbruiken om op afstand willekeurige OS-commando's uit te voeren, wat impact had op honderdduizenden downloads.

MCP-authenticatie wordt uitgevoerd via de transportlaag voordat de tool wordt uitgevoerd. De manier van uitvoering hangt af van hoe de MCP-server is gedeployed:

• STDIO-transport (lokale servers): Draait als een lokaal proces; MCP-authenticatie kan omgevingsvariabelen of systeem-credentials buiten MCP gebruiken.
• Streamable HTTP (remote servers): Draait over het netwerk zonder gedeeld vertrouwen tussen MCP-client en -server. MCP-authenticatie vindt plaats met behulp van OAuth 2.1 met access tokens die aan elk verzoek zijn gekoppeld.

In de praktijk:

• Lokale ontwikkeling: omgevingsgebaseerde credentials kunnen voldoende zijn.
• Remote productiesystemen: OAuth 2.1 is vereist voor een juiste authenticatie.

De drie typen MCP-authenticatie

Authenticatiemethoden die worden gebruikt in verschillende MCP-deployments, afhankelijk van de omgeving en risicotolerantie

API-sleutels en statische tokens

Het is een eenvoudige methode om bij elk verzoek een vooraf overeengekomen sleutel mee te sturen. 

Authorization: Bearer sk-xxxx

Wanneer het werkt: 

• Bij lokale ontwikkeling, en door een interne tool die binnen een goed gedefinieerde netwerkgrens opereert.

Beperkingen: 

• Statische tokens hebben geen vervaldatum
• Statische tokens bevatten geen gebruikersidentiteit
• Geen gedetailleerde permissies
• Statische tokens kunnen lekken via logs of versiebeheer, wat vrij risicovol is. 
• Wanneer statische tokens zijn blootgesteld, blijft de volledige toegangscontrole tot het gekoppelde systeem actief totdat deze handmatig wordt uitgeschakeld

OAuth 2.1 met PKCE (standaard voor remote MCP-servers)

Vanaf de MCP-specificatie-update van maart 2025 is de standaard voor het beveiligen van remote MCP-servers via MCP-authenticatie OAuth 2.1 met PKCE. In plaats van statische credentials gebruikt deze benadering een veilige, op tokens gebaseerde autorisatie-flow die Streamable HTTP mogelijk maakt.

Hoe het werkt:

• Metadata discovery: De MCP-client probeert de vereiste autorisatieserver-metadata van de server te ontdekken zonder access token en ontvangt een 401-respons. Het Protected Resource Metadata-document vertelt de client met welke autorisatieserver verbinding moet worden gemaakt en welke vereiste scopes beschikbaar zijn.
• Clientregistratie: De MCP-client registreert zich bij de autorisatieserver. De standaardmethode sinds november 2025 is via het CIMD-protocol. De client publiceert zijn Client ID Metadata op een openbare URL die hij beheert, en de autorisatieserver voert tijdens runtime een validatie van de clientinformatie uit.
• Autorisatiecode: De client meent de browser van de gebruiker, vraagt de gebruiker om in te loggen en toestemming te geven, en ontvangt een autorisatiecode van de autorisatieserver om namens hen te handelen.
• Uitgifte van access token: De client wisselt de autorisatiecode uit via de Authorization Code Flow voor een access token die is afgebakend voor de gevraagde resource, en voegt dit token toe aan elk MCP-verzoek.

Waarom PKCE belangrijk is:

• PKCE beschermt tegen onderscheppingsaanvallen door ervoor te zorgen dat de gebruiker die de MCP-authenticatie voltooit, dezelfde persoon is die deze heeft geïnitieerd.
• PKCE is verplicht voor alle MCP-clients vanaf november 2025 volgens de huidige MCP-specificatie.

Omgevingsgebaseerde credentials (STDIO-servers)

Lokale MCP-servers erven credentials van hun eigen runtime-omgeving.

Voordelen:

• Eenvoudig in te stellen zonder externe autorisatie-flow.

Nadelen:

• Credentials zijn toegankelijk voor elk proces dat toegang heeft tot het MCP-systeem, wat risico's creëert over gegevensbronnen heen.
• Moeilijk te beheren over meerdere personen of teams zonder gecentraliseerde autorisatielogica.
• Geen gecentraliseerde governance of toegangscontrole.

In productieomgevingen moet u uw credentials dynamisch ophalen met behulp van een veilige kluis (vault) in plaats van ze in plain-text op te slaan.

Hoe MCP OAuth 2.1-authenticatie stap voor stap werkt

Wanneer een MCP-client verbinding maakt met een beveiligde MCP-server, vindt de volgende MCP-flow plaats:

• Stap 1 — Client maakt verbinding, server weigert: De MCP-client probeert een verzoek te doen zonder token. De server reageert met een 401 Unauthorized-fout en een verwijzing naar zijn Protected Resource Metadata-URL als onderdeel van de discovery van de autorisatieserver.
• Stap 2 — Client haalt metadata op: Het metadata-eindpunt geeft aan welke autorisatieserver moet worden gebruikt, welke OAuth-scopes beschikbaar zijn en waar het token-eindpunt zich bevindt.
• Stap 3 — Client registreert zich en start de OAuth-flow: De client identificeert zichzelf met behulp van CIMD en zijn Client ID Metadata-document, maakt een PKCE code verifier en code challenge aan, en stuurt de browser van de gebruiker vervolgens door naar de inlogpagina van de autorisatieserver.
• Stap 4 — Gebruiker authenticeert en ontvangt de autorisatiecode: De gebruiker logt in en geeft toestemming. De autorisatieserver retourneert een autorisatiecode die de client met behulp van de oorspronkelijke code verifier kan inwisselen voor een kortstondig, afgebakend access token.
• Stap 5 — Client roept de MCP-server aan met bearer token: Elk MCP-verzoek bevat het access token in de Authorization Bearer-header. De MCP-server valideert de issuer, audience, vervaldatum en OAuth-scopes. Als het access token onvoldoende vereiste scopes bevat, reageert de server met een 403 en vraagt hij om aanvullende gebruikersautorisatie, een functionaliteit die in november 2025 is geïntroduceerd.

Waar gaat MCP-authenticatie nog steeds mis?

Veel deployments creëren ernstige MCP-beveiligingsrisico's door een onjuiste implementatie van MCP-authenticatie en -autorisatie, zelfs wanneer er gebruik wordt gemaakt van OAuth.

• Statische tokens in configuratiebestanden: API-sleutels die zijn gecommitteerd aan Git-repositories, gedeeld in mcp.json of .env-bestanden, en vervolgens zijn vergeten. Een enkele gecompromitteerde OAuth Client ID biedt onbeperkte toegang en verloopt nooit, wat een permanente bron van ongeautoriseerde toegang vormt.
• OAuth-scopes met te veel permissies: Gebruikers vragen tijdens de configuratie een groot aantal OAuth-scopes aan, maar beperken deze niet bij het uitvoeren van de applicatie. Een AI-agent die is geconfigureerd als read-only moet worden opgeslagen met een access token met alleen leesrechten, in plaats van een token met lees-/schrijf-/verwijderrechten.
• Geen token-rotatie in self-managed deployments: Langdurige OAuth-tokens die worden uitgegeven aan self-managed deployments zonder rotatieproces. Als een token gecompromitteerd raakt, blijft het functioneren als een geldig bearer token totdat iemand het handmatig uitschakelt.
• Geen audit trail voor tool calls: Wanneer een token wordt uitgegeven en externe tools worden aangeroepen, bestaat er geen record dat aangeeft wie het oorspronkelijke MCP-verzoek heeft gedaan. Dit maakt een onderzoek naar de hoofdoorzaak voor beveiligingsteams onmogelijk.

De meeste van deze problemen worden opgelost wanneer organisaties migreren van statische sleutels naar OAuth 2.1, wat kortstondige access tokens, afgebakende OAuth-scopes en gecentraliseerde audit logging via de autorisatieserver mogelijk maakt.

Enterprise MCP-authenticatievereisten vs. Hoe TrueFoundry ze oplost

TrueFoundry neemt de complexiteit weg van het beheren van meerdere vormen van MCP-authenticatie en -autorisatie over individuele teams heen, en past uniforme controles toe op alle MCP-servers via één enkele MCP-gatewaylaag.

Boek een demo om te begrijpen hoe MCP authenticatie afhandelt op infrastructuurniveau

Veelgestelde vragen

Wat is MCP-authenticatie? 

MCP-authenticatie is het proces van het verifiëren van de identiteit van een entiteit die verbinding probeert te maken met een MCP-server, met behulp van OAuth-tokens, API-sleutels of omgevingsvariabelen, afhankelijk van de context van de deployment. Het zorgt ervoor dat alleen geverifieerde AI-agents en MCP-clients toegang krijgen tot tools en externe services, en vormt de eerste laag van MCP-authenticatie en -autorisatie in elk productiesysteem.

Vereist MCP OAuth? 

Niet in elk geval. Een lokale STDIO-transportserver hoeft geen formele OAuth-flow te implementeren. Elk remote MCP-server die productiegevoelige gegevens of externe tools verwerkt, moet echter OAuth 2.1 met PKCE gebruiken als het standaard autorisatiemechanisme onder de huidige MCP-specificatie voor een juiste afdwinging van MCP-authenticatie en -autorisatie.

Heeft MCP authenticatie? 

MCP ondersteunt MCP-authenticatie en -autorisatie, en de methode hangt af van de serveromgeving. Remote servers gebruiken OAuth 2.1 PKCE als de standaard autorisatie-flow. Lokale STDIO-transportservers authenticeeren met behulp van credentials uit omgevingsvariabelen of het hostproces. De MCP-specificatie heeft OAuth 2.1 formeel verplicht gesteld als de standaard voor remote deployments vanaf maart 2025.

Wat zijn de typen MCP-authenticatie? 

Er bestaan drie veelvoorkomende methoden voor MCP-authenticatie en -autorisatie: statische API-sleutels voor interne of ontwikkelings-use cases, OAuth 2.1 met PKCE voor alle remote MCP-serverdeployments zoals vereist door de MCP-specificatie, en omgevingsgebaseerde credentials via omgevingsvariabelen voor lokale STDIO-transportservers waar een formele OAuth-clientregistratieflow niet vereist is.

Hoe werkt MCP-authenticatie? 

Wanneer een MCP-client verbinding maakt met een beveiligde MCP-server, retourneert de server een 401 met een verwijzing naar zijn Protected Resource Metadata-document. De client voert autorisatieserver-discovery uit, registreert zich met CIMD, voltooit de Authorization Code Flow met PKCE en ontvangt een afgebakend access token. Dit token wordt meegestuurd met elk inkomend verzoek voor tokenvalidatie voordat een tool call wordt toegestaan.

Hoe handelt TrueFoundry MCP-authenticatie af? 

Via de MCP-gateway centraliseert TrueFoundry MCP-authenticatie en -autorisatie door te integreren met enterprise identity providers en geautomatiseerde uitgifte, rotatie en validatie van access tokens af te handelen. OAuth-scopes en RBAC-beleidsregels worden afgedwongen op de gatewaylaag over alle MCP-servers heen, waarbij gestructureerde audit logs binnen de VPC van de klant worden bewaard voor compliance over AI-agents en externe services heen.