MCP Authentication en Authorization: De Belangrijkste Verschillen Uitgelegd

Wanneer een AI-agent verbinding maakt met een MCP-server, moet de agent zijn identiteit verifiëren (MCP authentication) en de functies definiëren die hij mag uitvoeren zodra toegang is verleend (MCP authorization) om de beveiliging voor zowel de MCP-client als het systeem te waarborgen. Het is van cruciaal belang om onderscheid te maken tussen deze twee typen toegangscontrolecontroles.

Wanneer beveiligingscontroles onjuist of door elkaar worden gebruikt, ontstaan er beveiligingslekken die uitdagingen vormen voor gebruikers en beheerders van traditionele systemen. In MCP-omgevingen veroorzaakt het ontbreken van gedefinieerde beveiligingscontroles ernstigere risico's dan in traditionele systemen.

Deze gids biedt gedetailleerde beschrijvingen van MCP authentication en authorization, hoe ze functioneren binnen het model context protocol-ecosysteem, en wat er nodig is om deze concepten te implementeren voor succesvolle enterprise-adoptie in een live productie-omgeving.

Wat is MCP Authentication?

MCP authentication is het eerste verificatiepunt tussen een MCP-client en een MCP-server. Voordat een commando via tools wordt uitgevoerd, moet de client zichzelf identificeren en authenticeren om vertrouwen op te bouwen. Om te authenticeren bij externe MCP-servers (HTTP/HTTPS) is het meest gebruikte authorization-mechanisme OAuth 2.1 met PKCE.

Wanneer een agent zich succesvol authenticeert bij een authorization-server, wisselt de client referenties in voor een OAuth token, vaak via een token exchange die wordt gestart bij het metadata endpoint. De MCP-server staat geen verbinding toe tenzij de agent beschikt over een geldig OAuth-token.

In tegenstelling tot de standaard verbindingsmethoden vereisen lokale MCP-servers die verbinding maken via STDIO-transport niet dat een agent zich authenticeert. In plaats daarvan gebruiken ze de trust boundary van het hostproces, die in eenvoudige use-cases vaak wordt geconfigureerd via omgevingsvariabelen.

De meest gebruikte typen referenties zijn als volgt:

• OAuth 2.1 Access Tokens: Kortstondig (meestal één uur) en beperkt in scope; dit is het aanbevolen referentietype voor veilige toegang in enterprise-grade productiesystemen.
• API keys: Eenvoudig te gebruiken, zonder vervaldatum of fijmazige toegangscontrole; dit referentietype wordt als risicovol beschouwd bij het beheren van veel gebruikers over externe systemen heen.
• JWT's: Claims over de identiteit van gebruikers, zoals gebruiker, rol en tenant, zijn ingebed in het JWT, hoewel ze extra complexiteit met zich meebrengen vanwege de noodzaak voor aanvullende authorization-logica.
  

Sinds de update van juni 2025 voor de MCP-specificatie worden servers nu behandeld als OAuth resource servers. Ze valideren tokens, maar geven geen tokens uit aan gebruikers. In plaats daarvan is de verantwoordelijkheid voor het uitgeven van tokens verplaatst naar externe identity providers zoals Okta, Azure AD en Auth0.

Dit creëert één enkel punt voor MCP authentication en brengt SSO, MFA en auditeerbaarheid op identiteitsniveau naar het MCP-ecosysteem, zonder dat daarvoor maatwerkimplementaties nodig zijn.

Wat is MCP Authorization?

Authentication stelt de identiteit van de client vast, terwijl MCP authorization de mogelijkheden van de client bepaalt.

Authorization regelt toegangscontrole op een zeer gedetailleerd niveau en biedt beperkingen voor welke tools mogen worden aangeroepen, welke data mag worden geraadpleegd en onder welke voorwaarden die acties mogen worden uitgevoerd. Authorization wordt continu geëvalueerd bij elke tool-aanroep, in plaats van als een eenmalige beoordeling.

In MCP-systemen gebruikt authorization doorgaans een gelaagde aanpak. De authorization-lagen in MCP-systemen omvatten:

• Op Scope Gebaseerde Permissies: Permissies die zijn gedefinieerd bij de tokenuitgifte en die de uiterste grenzen bepalen van alle mogelijke OAuth-scopes en uitgevoerde acties.
• Role-Based Access Control (RBAC): Koppeling van permissies aan rollen om ervoor te zorgen dat elke gebruiker en alle AI-agents die dezelfde rol gebruiken, dezelfde rechten hebben om toegang te krijgen tot die resources.
• Resource-level Controls: Beperking van veilige toegang tot specifieke datasets, tools of omgevingen.
• Contextuele Policies: Toepassen van runtime-voorwaarden zoals tijd, verzoekpatronen of risicosignalen op het bovenstaande.

De laatste authorization-laag vertegenwoordigt het meest interessante aspect van het moderne MCP authorization-framework. Een token dat is geautoriseerd om de read_file-methode om 9:00 uur aan te roepen, kan ook worden geweigerd om dezelfde methode om 2:00 uur aan te roepen op basis van een andere policy die van toepassing is op de eerste twee referentieparameters.

Authentication vs Authorization in MCP: De Belangrijkste Verschillen

Hoewel authentication en authorization soms worden verward, vertegenwoordigen ze een tweeledige aanpak in de context van MCP. De twee gebieden bieden verschillende niveaus van toegangscontrole, en de foutmodi van elk verschillen dienovereenkomstig.

Als authentication correct is maar de juiste authorization niet wordt gehandhaafd, wordt elke geauthenticeerde client een superuser.

De foutmodi staan vaak lijnrecht tegenover elkaar:

• Zwakke MCP authentication laat onjuiste identiteiten toe.
• Zwakke MCP authorization staat toe dat correcte identiteiten overmatige acties uitvoeren.

MCP-systemen in productie vereisen dat beide typen controle onafhankelijk van elkaar worden gehandhaafd.

Hoe Werken MCP Authentication en Authorization Samen in een Echte MCP-Flow?

Hieronder volgt een feitelijk voorbeeld van een reeks stappen die plaatsvinden wanneer een agent contact opneemt met een externe MCP-server. Dit leidt tot een succesvolle tool-call of resulteert in een fout.

Stap 1: De agent probeert verbinding te maken met de MCP-server als een MCP-client. De MCP-server herkent niet dat de client een openstaande sessie heeft en retourneert daarom een 401 Unauthorized-respons, samen met de metadata van de authorization-server die verwijst naar de authorization-server.

Stap 2: De agent stuurt een redirect-verzoek naar de authorization-server (Okta, Azure AD of Auth0), waar de OAuth-flow met PKCE wordt voltooid. De gebruiker of service authenticeert zich en stemt in met de gevraagde OAuth-scopes, waarna deze een authorization code ontvangt.

Stap 3: Na het ontvangen van een authorization code van de authorization-server, gebruikt de agent de authorization code flow om een access token te verkrijgen via het token endpoint. Een access token biedt de agent tijdelijke veilige toegang, bevestigt de authenticiteit van de communicatie en beperkt de agent tot de goedgekeurde OAuth-scopes die zijn aangevraagd namens de verzoekende applicatie.

Stap 4: Na het verkrijgen van een access token communiceert de agent met MCP door het access token op te nemen in de Authorization header als een bearer token. De MCP-server valideert de handtekening, vervaldatum en uitgevende entiteit van het token tegen de openbare sleutels van de authorization-server tijdens de tokenvalidatie om de identiteit van de agent te bevestigen.

Stap 5: Wanneer de agent de MCP-server aanroept met de tools:read scope, controleert de MCP-server eerst of de scopes van de access tokens overeenkomen met de gevraagde actie. Omdat de tools:read scope geen destructieve acties toestaat, retourneert de MCP-server een 403 Forbidden Response Code en legt de geweigerde toegang vast als onderdeel van de authorization-flow.

Stap 6: Om te voorkomen dat ongeautoriseerde geautomatiseerde workflows verkeerd geconfigureerde servers bereiken, wordt er een policy engine of een MCP gateway voor de MCP-server geplaatst. De policy engine controleert of elke tool-aanroep geen rate limits overschrijdt of contextgebaseerde policies of op scope gebaseerde regels schendt, voordat het verzoek wordt doorgelaten naar de serverlogica.

Waar Gaat het Mis bij Teams met MCP Authentication en Authorization?

Zelfs teams die beide lagen gebruiken, passen ze vaak verkeerd toe.

• Een geldig token behandelen als een algemene toestemming: Sommige bedrijven gebruiken geldige tokens voor algehele toegang. Ontwikkelaars maken daardoor vaak nieuwe tokens aan die hen rechten geven die ze niet zouden moeten hebben. Via deze tokens krijgen ze per abuis toegang tot productiedatabaseresources, hetzij op ontwikkelaarsniveau, hetzij door beveiligingsfouten rond token-authentication, terwijl het token in eerste instantie zo was ingesteld dat de ontwikkelaar die rechten kreeg.
• Authorization overgeslagen voor interne MCP-servers: Een netwerkgrens alleen garandeert niet dat men er geen toegang toe kan krijgen. Iemand met interne toegang kan toegang krijgen tot alle interne resources op de interne server voor verkooporderverwerking.
• Statische API keys gebruikt zonder een geschikte authorization stack: Statische API keys beschikken mogelijk niet over OAuth-scopes, een vervaldatum of intrekkingsmechanismen. Als een statische API key uitlekt in een logbestand of repository, is de enige oplossing het roteren van de referenties, wat op schaal operationeel verstorend is.
• Uitsluitend vertrouwen op OAuth-scopes zonder RBAC op gateway-niveau: OAuth-scopes bepalen wat het token binnen een sessie kan uitvoeren, terwijl rollen bepalen wat de persoon is toegewezen om uit te voeren. Als RBAC niet wordt gehandhaafd op gateway-niveau, heeft een geautomatiseerde pipeline dezelfde toegang als een menselijke engineer.
• Toegang niet opnieuw evalueren nadat aan het begin van een sessie toestemming is verleend: Wanneer een AI-agent aan het begin van de sessie toestemming krijgt om zijn functie uit te voeren en de rol van de agent gedurende de sessie wijzigt, blijven alle voorafgaand aan die wijziging verleende permissies van kracht voor de gehele periode. Dit is een aanzienlijk risico in agentic systemen waar autonome agents gedurende langere sessies actief kunnen zijn.

Wat Vereist een Enterprise-Implementatie van MCP Authentication en Authorization? 

Het is voor teams of individuele serverimplementaties niet haalbaar om MCP authentication en MCP authorization op schaal zelf af te handelen. In plaats daarvan moeten ze over meerdere servers heen op platformniveau worden geïmplementeerd.

Om dit te bereiken, moet met het volgende rekening worden gehouden:

• Gecentraliseerd identiteitsbeheer via een identity provider: Alle MCP authentication-verzoeken over alle MCP-servers moeten via dezelfde identity provider verlopen, of dat nu Okta, Azure AD of Auth0 is. Een gedistribueerde authentication-configuratie schaalt niet en zorgt voor fragmentatie in audit trails.
• Door de infrastructuur afgedwongen kortstondige scoped tokens: Alle MCP-servers moeten kortstondige access tokens met gedefinieerde OAuth-scopes afdwingen via de infrastructuur. Het team kan de tokenvervaldatum of scope niet voor elke deployment afzonderlijk op een correcte manier definiëren, maar de infrastructuur zal deze consistent afdwingen.
• RBAC per server en rol met onmiddellijke policy-doorgifte: Wanneer een team de rol van een gebruiker of teamlid wijzigt, moet de wijziging onmiddellijk worden doorgevoerd naar alle servers en van kracht worden zonder te wachten op de volgende deploymentcyclus.
• Unieke gecombineerde audit trails voor toegangs- en authorization-logs: Zowel toegangslogs als MCP authorization-logs zijn nodig voor verschillende teams. Beide teams hebben toegang nodig tot gecombineerde audit trails met een gemeenschappelijke request-ID voor toekomstige onderzoeken.
• Afdwinging van toegangscontrole op de gateway, gescheiden van applicatiecode: Als de applicatiepolicy in de server is opgeslagen en de server verkeerd wordt gedeponeerd, kan de applicatiepolicy onopgemerkt worden uitgeschakeld. De MCP gateway zal echter zowel OAuth-scopecontroles als rate limits afdwingen, ongeacht het gedrag van de applicatie.

Hoe Dwingt TrueFoundry MCP Authentication en Authorization af op de Platformlaag?

TrueFoundry behandelt MCP authentication en authorization als fundamentele concepten van zijn platform, niet als taken die door individuele applicaties moeten worden uitgevoerd.

• Enterprise IdP-integratie out-of-the-box: TrueFoundry stelt organisaties in staat hun enterprise identity provider te koppelen met behulp van Okta, Azure AD of elke OAuth authorization-server die OAuth 2.0 ondersteunt. Authentication-tokens worden geconfigureerd en identiteitsverificatie vindt plaats via de bestaande identiteitsinfrastructuur van de organisatie. Organisaties hoeven geen extra authorization-server aan te maken of te beheren om hun applicaties te voltooien.
• RBAC per server gehandhaafd op de gateway, niet in de applicatie: Door toegangscontrole af te dwingen op de MCP gateway voordat een verzoek de applicatielogica van de MCP-server bereikt, zorgt TrueFoundry ervoor dat toegangspolicies worden gehandhaafd over meerdere MCP-instanties, ongeacht hoe elke applicatie-instantie is ontwikkeld of geconfigureerd.
• Scoped toegang die organisatierollen koppelt aan tool-permissies: TrueFoundry ondersteunt MCP authorization scoping, waarbij de ene groep (zoals Finance) wordt toegewezen aan één set tools en een andere groep (zoals Support) aan een andere. Een Finance-agent en een Support-agent kunnen toegang krijgen tot dezelfde MCP-infrastructuur terwijl ze verschillende tool-permissies hebben. De koppeling tussen rollen en OAuth-scopes wordt eenmalig op het platform gedefinieerd en geldt voor alle instanties.
• Geünificeerde audit trail binnen uw VPC: TrueFoundry biedt één geconsolideerde audit trail binnen de VPC van de klant voor gebeurtenissen die verband houden met tokenvalidatie en tool-aanroepen. Beveiligingsteams hebben toegang tot een volledige, tijdsgecorreleerde audit trail. Alle gebeurtenissen rond tokenvalidatie en tool-aanroepen bevatten een uniforme request-ID, wat het eenvoudig maakt om gebeurtenissen met betrekking tot een specifieke gebruiker te identificeren over large language models en externe tools heen.
• Platformstandaard, geen configuratie per team: MCP authentication- en MCP authorization-functies zijn standaard ingeschakeld voor alle organisaties. Deze policies worden altijd overgenomen door MCP-applicaties bij het implementeren van AI-agents, zodat teams niet hun eigen policies hoeven te maken of de juiste authentication hoeven te implementeren in elke nieuwe MCP-server.

TrueFoundry biedt MCP authentication en authorization als fundamentele platformmogelijkheden, in plaats van als een individuele configuratielast voor de organisaties die de tools gebruiken.

Veelgestelde Vragen

Wat is MCP authentication en MCP authorization?

MCP authentication en MCP authorization zijn twee afzonderlijke beveiligingsconcepten. MCP authentication bevestigt de identiteit van de MCP-client voordat toegang wordt verleend, met behulp van OAuth-tokens of API keys. MCP authorization bepaalt wat de geauthenticeerde client kan doen via OAuth-scopes en RBAC. Beide zijn vereist in elke MCP-serverinstallatie in productie om beveiligingsrisico's door ongeautoriseerde toegang te voorkomen.

Wat is het verschil tussen authentication en authorization in MCP?

MCP authentication vindt eenmalig plaats bij het maken van de verbinding en gebruikt de authorization code flow of client credentials flow om de identiteit te verifiëren. MCP authorization wordt geëvalueerd bij elke tool-aanroep tijdens de verbinding, waarbij OAuth-scopes en RBAC-regels worden toegepast op elk verzoek dat de AI-agent via de MCP-server doet.

Kun je MCP authorization hebben zonder authentication?

Er is geen zinvolle MCP authorization mogelijk zonder MCP authentication, omdat er geen geauthenticeerde identiteit is waartegen permissies kunnen worden geëvalueerd. Zonder de juiste authentication om de identiteit vast te stellen, heeft de authorization-server geen basis voor het uitgeven van access tokens of het toepassen van authorization-logica op inkomende verzoeken van AI-agents of autonome agents.

Wat komt eerst, MCP authentication of MCP authorization?

MCP authentication komt altijd eerst. De authorization-flow stelt de identiteit van de MCP-client vast bij de authorization-server. MCP authorization vindt vervolgens plaats voor elk volgend verzoek nadat de client-authentication is voltooid en access tokens met gedefinieerde OAuth-scopes zijn uitgegeven.

Ondersteunt TrueFoundry bring-your-own IdP?

Ja. TrueFoundry integreert met elke identity provider of OAuth authorization-server die voldoet aan OAuth 2.0, waardoor organisaties hun bestaande identiteitsinfrastructuur kunnen hergebruiken. Dit omvat ondersteuning voor externe identity providers zoals Okta en Azure AD, wat gecentraliseerde MCP authentication over alle MCP-servers mogelijk maakt zonder dat er een afzonderlijke authorization-serverconfiguratie hoeft te worden aangemaakt.