MCP-server beveiligen: OAuth voorkomt geen accountovername

OAuth op een externe MCP-server sluit accountovername niet uit. De server moet vóór iedere beschermde aanvraag vaststellen dat het toegangstoken voor hem is uitgegeven; de autorisatiestroom moet een gestolen code, een afwijkende redirect en ontbrekende toestemming afwijzen. De MCP-beveiligingsregels stellen hiervoor eisen aan tokenvalidatie, PKCE, HTTPS en redirect-URI’s.

Dat een OAuth-stroom werkt, bewijst alleen dat een toegestane route werkt. In een onderzoek naar externe MCP-servers had elk van de 119 geteste servers met OAuth minstens één fout; de onderzoekers telden 325 fouten, waarvan fouten rond dynamische clientregistratie bij 96,6% van die groep voorkwamen, en verkregen negen CVE-identificaties. Veel van de gevonden fouten kunnen volgens de onderzoekers leiden tot uitlekken van gegevens of accountovername. Deze uitkomsten gelden voor de onderzochte servers, niet automatisch voor iedere implementatie.

Bescherm de grens van iedere tool

Bepaal eerst welke tools, bronnen en resultaten alleen voor bevoegde gebruikers beschikbaar zijn. Stuur voor elke beschermde handeling een aanvraag zonder token en daarna een aanvraag met een verlopen of ongeldig token. Verwacht een HTTP 401 zonder beschermd toolresultaat of afgeschermde gegevens; voer dezelfde proef uit voor tools/list als de catalogus zelf beschermd is. Een bewust openbare tool vraagt om een afzonderlijke, expliciete toegangsregel.

De MCP-autorisatiespecificatie vereist dat een beschermde server metadata aanbiedt waarmee de client zijn autorisatieserver kan vinden. Controleer of de 401-uitdaging naar de juiste metadata verwijst en of de client zijn Bearer-token in de Authorization-header van iedere HTTP-aanvraag meestuurt. Een token in de URL-querystring hoort niet te worden gebruikt. Test ook een rechtstreeks aangeroepen tool: toegang mag niet afhangen van een eerdere, geslaagde aanvraag voor de catalogus.

Controleer de bestemming van het token

De belangrijkste afwijzing betreft een geldig token voor de verkeerde ontvanger. Laat een client in het autorisatieverzoek én het tokenverzoek de parameter resource meesturen met de canonieke URI van de bedoelde MCP-server. Bied de server vervolgens een token aan dat voor een andere MCP-server of API is uitgegeven. Ook als de handtekening geldig is en de uitgever bekend is, moet de aanvraag zonder beschermd resultaat eindigen.

Controleer bij een JWT of de audience de eigen server omvat; gebruik bij een ander tokenformaat een passende validatie van de bedoelde ontvanger. Test daarnaast een ontbrekende of gewijzigde resource-parameter en kijk of de resulterende stroom ergens toch toegang tot de beschermde handeling geeft. De autorisatieserver kan zo’n verzoek zelf afwijzen, maar de MCP-server blijft verantwoordelijk voor de controle van het token dat hij ontvangt. Een MCP-server die namens de gebruiker een externe API aanroept, heeft voor die API een afzonderlijk bedoeld token nodig; het ontvangen clienttoken doorsturen doorbreekt deze scheiding.

Laat codes en redirects geen omweg bieden

PKCE bindt de autorisatiecode aan de client die de stroom begon. Controleer eerst of de metadata van de autorisatieserver PKCE-ondersteuning vermelden; zonder die vermelding moet de MCP-client de autorisatie stoppen. Gebruik S256 wanneer dat technisch mogelijk is. Simuleer daarna een onderschepte code en probeer die in te wisselen zonder code_verifier en met een verkeerde verifier. Beide verzoeken moeten mislukken; alleen de juiste verifier mag de oorspronkelijke stroom voltooien.

Alle eindpunten van de autorisatieserver moeten HTTPS gebruiken. Redirect-URI’s moeten HTTPS gebruiken of naar localhost verwijzen. Registreer de toegestane URI’s vooraf en verander in een negatieve test de host, het pad of een queryparameter. De autorisatieserver moet de afwijkende URI exact als niet geregistreerd herkennen en mag de code er niet naartoe sturen. Controleer ook de state-waarde als de client die gebruikt: een afwijkende waarde hoort de respons ongeldig te maken.

Werkt een client met meerdere autorisatieservers, bewaar dan per autorisatieverzoek de verwachte uitgever. Laat in een test een respons met een iss-waarde van een andere uitgever binnenkomen. De client moet die waarde vergelijken vóór hij de code naar een token-eindpunt stuurt en de respons bij een afwijking weigeren. Kondigt de metadata ondersteuning voor iss aan, dan moet ook een respons zonder iss worden geweigerd.

Geef registratie geen bestaande toestemming mee

Dynamische clientregistratie is optioneel en in de MCP-specificatie behouden voor compatibiliteit; vooraf geregistreerde clients en Client ID Metadata Documents zijn andere routes. Als dynamische registratie aanstaat, kan een onbekende client mogelijk een eigen redirect-URI registreren. Test dat scenario met een domein onder controle van de testclient. Open registratie is op zichzelf niet de te bewijzen fout: de nieuwe client mag geen identiteit of toestemming erven die aan een andere client is verleend, en de autorisatieserver moet bij gebruik opnieuw de exacte geregistreerde redirect-URI controleren.

Bij een MCP-proxy met een vaste client-ID voor een externe autorisatieserver is die scheiding bijzonder belangrijk. Registreer als negatieve test een tweede client nadat de gebruiker de eerste heeft goedgekeurd en start via de proxy een nieuwe autorisatiestroom. De proxy moet vóór het doorsturen toestemming voor juist die tweede client verkrijgen. Eerdere toestemming stilzwijgend hergebruiken kan een aanvaller met een gestolen autorisatiecode een route naar een toegangstoken geven zonder bewuste goedkeuring van de gebruiker.

Beperk rechten en maak afwijzingen reproduceerbaar

Controleer scopes bij de uitvoering van elke beschermde handeling. Een token met alleen leesrechten mag geen schrijfactie uitvoeren, ook wanneer de client de naam van de schrijftool kent of die eerder in een catalogus zag. Verwacht bij een geldig token met onvoldoende rechten een HTTP 403; een uitdaging met insufficient_scope kan de voor die handeling benodigde scopes vermelden. Vraag aanvullende rechten pas wanneer de handeling ze nodig heeft en test daarna opnieuw met een token dat de vereiste scope wel heeft.

Leg de negatieve verzoeken vast als regressietests over de volledige route van client, autorisatieserver, eventuele proxy en MCP-server. Controleer per geval zowel de foutrespons als de afwezigheid van beschermde gegevens: geen of verlopen token, verkeerde tokenbestemming, onjuiste PKCE-verifier, gewijzigde redirect-URI, verwisselde uitgever, nieuwe client zonder toestemming en onvoldoende rechten. Herhaal die tests na wijzigingen aan metadata, registratiebeleid, scopes of proxyconfiguratie. Zo blijft zichtbaar welke specifieke beveiligingsgrens een wijziging heeft verzwakt.