MCP-authenticatie: waarvoor geef je eigenlijk toestemming?

Je koppelt een remote MCP-server en er verschijnt een inlogvenster. Je account herkennen is één stap. Daarna volgt de belangrijkere vraag: welke toepassing krijgt toegang tot welke informatie, en wat mag die ermee doen? Bij MCP-authenticatie lopen identiteit, toestemming en technische uitvoering al snel door elkaar.

Neem een zelfbedachte situatie. Een klein reparatiebedrijf bewaart interne apparaathandleidingen in een bibliotheek. Een medewerker wil zijn AI-assistent daarin laten zoeken. Het doel is één onderhoudsinstructie vinden. Daarvoor hoeft de assistent geen documenten te verwijderen, collega's te beheren of de hele bibliotheek te exporteren.

Bij OAuth voor remote MCP is de MCP-client de aanvragende software. De MCP-server is de beschermde resource die gereedschap of gegevens aanbiedt. De autorisatieserver regelt de aanmelding en geeft toegangstokens uit. De MCP-autorisatiespecificatie van 28 juli 2026 beschrijft deze rolverdeling voor HTTP-transporten.

In onze casus werkt de medewerker met een AI-toepassing, de MCP-server ontsluit handleidingen en een inlogdienst beoordeelt de account. Die onderdelen kunnen van verschillende aanbieders zijn. Controleer daarom wie de koppeling beheert. Alleen een bekend logo in het chatvenster vertelt je onvoldoende over de partij die straks de documenten ontvangt.

Met aanmelden stel je vast welke account je gebruikt. Met toestemming keur je een afgebakende toegang goed. Een scope beschrijft een bevoegdheid die een dienst kent. De precieze namen verschillen per aanbieder; een verzonnen scope uit een tutorial is geen instelling die je overal kunt overnemen.

Voor het reparatiebedrijf zou ik de gewenste toestemming eerst in gewone taal opschrijven: zoek in de goedgekeurde handleidingen en lees een geselecteerd document. Kijk daarna of het echte toestemmingsscherm daarbij past. Vraagt het ook om documenten te wijzigen, stel dan vast waarom. Ontbreekt een beperkte optie, dan is dat een reden om de inrichting te herzien. Een ruimere knop aanklikken maakt de taak niet kleiner.

De client vraagt een token aan voor de MCP-server. De standaard over OAuth Resource Indicators legt uit hoe een aanvraag de bedoelde resource aangeeft. De server moet vervolgens controleren of het aangeboden token voor zijn eigen resource geldig is. Een willekeurig geldig token voor een andere dienst volstaat niet.

Stel dat de handleidingenserver achter de schermen een apart opslagsysteem aanspreekt. Dat voegt een tweede toegangsgrens toe. De server mag het inkomende token niet blind doorgeven alsof het overal geldig is. De MCP security best practices verbieden die token-passthrough. Laat de dienstbeheerder een ondersteunde autorisatieroute voor de achterliggende API gebruiken.

De medewerker begint met een concrete vraag: vind de onderhoudsinstructie voor de fictieve pomp RP-4. Vóór bevestiging controleert hij de aanvragende client, de account en de gevraagde toegang. Klopt de account niet, dan stopt hij en kiest de juiste. Een privéaccount mag geen sluiproute worden naar een bedrijfsbibliotheek.

Vervolgens bekijkt hij welke informatie na koppeling beschikbaar is. Kan de assistent alleen de afgesproken verzameling lezen? Of ook personeelsdocumenten die toevallig in hetzelfde opslagsysteem staan? Het antwoord vraagt om een technische controle met de beheerder. Een toestemmingsscherm met het woord “lezen” bepaalt niet vanzelf welke mappen of organisaties zijn afgeschermd.

Maak ook duidelijk wie toegang mag intrekken. In deze oefening hoort de medewerker de verbinding terug te kunnen vinden en moet een beheerder kunnen nagaan welke dienst eraan hangt. Dat maakt stoppen een normale beheerhandeling.

Plak geen access token, refresh token, wachtwoord of client secret in een prompt, skillbestand of voorbeeldgesprek. De assistent hoeft de sleutel niet te kunnen navertellen om namens jou een toegestane tool te gebruiken. Gebruik de door de client en aanbieder ondersteunde opslag- en aanmeldroute. In Claude Code loopt aanmelden bij ondersteunde remote servers via de MCP-bediening.

Let ook op hulpvragen. Een screenshot van de fout kan onbedoeld een token bevatten. Deel de servernaam, de handeling en een opgeschoonde foutmelding. Bewaar geen volledig inlogantwoord als gewoon projectdocument. De handleiding van pomp RP-4 mag straks in het antwoord staan; de sleutel waarmee hij is opgehaald niet.

Laat de assistent na koppeling één vooraf bekend oefendocument vinden. Vraag om titel, document-ID en de relevante onderhoudsstap. Vergelijk die met de bibliotheek. Controleer daarnaast met een afzonderlijke beperkte testaccount dat een afgeschermd document niet beschikbaar komt. Het verbergen van een zoekresultaat is onvoldoende als een directe opvraag nog wel lukt.

Haal tijdens die proef geen echte personeelsdossiers op. Je kunt het toegangsverschil testen met twee zelfgemaakte documenten zonder persoonsgegevens. Noteer welke identiteit de proef uitvoerde. Zo is later te onderscheiden of een fout in de koppeling zit of in de rechten van de gebruikte account.

Bij een verlopen aanmelding volg je de normale heraanmeldroute. Vraag de assistent niet naar een omweg met een andere sleutel. Een toegangsweigering kan precies het afgesproken gedrag zijn.

Leg voor het reparatiebedrijf vast wie eigenaar is van de handleidingenverbinding, welke verzameling beschikbaar hoort te zijn en wanneer je de toegang opnieuw bekijkt. Bij een nieuwe opslaglocatie of vertrekkende medewerker verandert die afspraak. Controleer dan ook bestaande verbindingen.

De handleiding voor MCP in Claude Code behandelt het aansluiten. Voor het kiezen van een passende oefentaak kun je verder in de gids over AI coding. Begin bij de informatie die je nodig hebt en laat de toestemming daarbij aansluiten. Dat levert een koppeling op die je ook aan een collega kunt uitleggen.