MCP Authentication in Cursor: OAuth, API Keys en veilige configuratie (Handleiding 2026)

MCP-authenticatie bepaalt hoe de AI-agent van Cursor bewijst wie hij is wanneer hij verbinding zoekt met externe tools en diensten. Sla dit over, en elke MCP-server draait volledig open of is afhankelijk van een statisch token in platte tekst. Doe het goed, en de agent verbindt met GitHub, Slack of je interne API's met referenties die gecoped, roteerbaar en auditeerbaar zijn.

De MCP-specificatie introduceerde gestandaardiseerde OAuth 2.1-autorisatie in de herziening van maart 2025. Juni 2025 volgde met een formele scheiding tussen MCP-servers en autorisatieservers en verplichtte Protected Resource Metadata (RFC 9728). De herziening van november 2025 bracht vervolgens Client ID Metadata Documents (CIMD) als de aangewezen registratiemethode en maakte PKCE verplicht voor elke client. Cursor ondersteunt OAuth sinds v1.0 (juni 2025) en behoort daarmee tot de eerste IDE's die browsergebaseerde MCP-authenticatie bieden.

Het begrijpen van het authenticatiemodel van Cursor is om twee redenen de moeite waard: het bepaalt waar je agent bij kan, en het definieert de impact wanneer er iets misgaat.

Hoe MCP-authenticatie werkt

MCP-authenticatie bevindt zich op de transportlaag. Welk mechanisme je krijgt, hangt af van het feit of de server lokaal draait via stdio of op afstand via Streamable HTTP.

Stdio-servers afhandelen authenticatie volledig buiten het MCP-protocol om. Het serverproces erft omgevingsvariabelen van Cursor — meestal API-sleutels of tokens — en gebruikt deze om te authenticeren bij bovenliggende diensten zoals de GitHub-API, een database of een cloudprovider. De MCP-specificatie is hier expliciet in: stdio-implementaties moeten referenties uit de omgeving halen, niet uit een OAuth-flow.

Remote servers via Streamable HTTP volgen een ander pad. De MCP-specificatie adviseert OAuth 2.1, en de handshake omvat drie partijen:

Cursor vervult de rol van OAuth-client. De MCP-server fungeert als een OAuth 2.1-resourceserver — deze valideert tokens, maar geeft ze nooit uit. Een autorisatieserver (Okta, Auth0, Azure AD, of een server die door de MCP-serverbeheerder wordt beheerd) verzorgt de gebruikersauthenticatie en geeft tokens uit.

Dit is de werkelijke volgorde. Cursor stuurt een verzoek naar de MCP-server zonder token. De server reageert met 401 Unauthorized en een WWW-Authenticate header die verwijst naar het Protected Resource Metadata-document. Cursor haalt dat document op, bepaalt welke autorisatieserver moet worden aangesproken, registreert zichzelf (via Dynamic Client Registration of CIMD) en opent een browservenster waarin je kunt inloggen.

Zodra je autoriseert, geeft de autorisatieserver een toegangstoken uit. Cursor slaat dat token op en voegt het toe aan elk volgend verzoek.

PKCE (Proof Key for Code Exchange) doorloopt de gehele flow. Cursor genereert een code_verifier en code_challenge paartje voordat de flow start. Zelfs als een kwaadwillende erin slaagt de autorisatiecode onderweg te onderscheppen, kan deze niet worden ingewisseld voor een token zonder de originele verifier.

Authenticatiemethoden in Cursor

Cursor biedt drie manieren om MCP-servers te authenticeren. Elk van deze methoden is geschikt voor een ander implementatiescenario.

Omgevingsvariabelen voor stdio-servers

De meeste lokale MCP-servers bewijzen hun identiteit aan bovenliggende API's via omgevingsvariabelen. Cursor injecteert deze in het serverproces tijdens het opstarten.

Het env-veld accepteert sleutel-waarde-paren. Cursor geeft ze rechtstreeks door aan het gestarte proces. Je token verschijnt niet in de UI of logs van Cursor. Maar het staat wel in platte tekst in mcp.json. Commit je dat bestand naar Git, dan verzend je direct je referenties naar elke bijdrager — of erger, naar een openbare repository.

Oplossing: Verwijs naar omgevingsvariabelen op systeemniveau met de ${env:VARIABLE_NAME} syntaxis in plaats van ruwe waarden te plakken:

Nu staat het echte token in je shell-profiel of een secrets manager. Het bestand mcp.json bevat alleen een verwijzing, zodat je het veilig kunt opnemen in versiebeheer.

Statische headers voor remote servers

Sommige remote servers ondersteunen geen OAuth. In dat geval kun je een statische API-sleutel of Bearer-token doorgeven via HTTP-headers. Cursor stuurt deze headers mee met elk verzoek naar het server-endpoint.

De referentiesyntaxis voor omgevingsvariabelen werkt ook in headers:

Statische headers zijn zeer eenvoudig in te stellen. Ze dragen echter alle nadelen van langlopende referenties met zich mee: geen vervaldatum, geen scoping per sessie, en bij het roteren ervan moet je het configuratiebestand van elke ontwikkelaar aanpassen.

OAuth 2.1 voor remote servers

OAuth is wat de MCP-specificatie aanbeveelt voor remote servers, en Cursor v1.0 voegde hier nattieve ondersteuning voor toe. Zo ziet het proces er van begin tot eind uit:

1. Voeg een remote server URL toe aan mcp.json — er zijn geen auth-headers nodig.
2. Open Cursor Settings → Tools & MCP. De server verschijnt met een blauwe knop Connect en het label "Needs authentication" onder de naam.
3. Klik op Connect. Cursor opent je standaardbrowser en navigeert naar de inlogpagina van de autorisatieserver.
4. Log in en verleen de gevraagde machtigingen.
5. Na autorisatie redirect de browser naar cursor://anysphere.cursor-mcp/oauth/callback. Je besturingssysteem stuurt de callback terug naar Cursor, dat de autorisatiecode via PKCE met S256 inwisselt voor tokens.
6. De tools van de server verschijnen in de lijst met MCP-tools, gereed voor gebruik door de agent.

De JSON-configuratie voor een server met OAuth-ondersteuning is minimaal omdat het ook echt minimaal is:

Geen tokens. Geen headers. Cursor regelt alles via de discovery-flow van de specificatie — de Protected Resource Metadata van de server geeft aan waar Cursor heen moet, en PKCE beveiligt de tokenuitwisseling.

Deep links met één klik werken eveneens goed met OAuth. Klik op een "Add to Cursor"-link op de documentatiepagina van een server, en Cursor start direct de OAuth-flow als de server dat vereist.

Beveiligingsrisico's bij authenticatie

MCP-authenticatie brengt beveiligingsrisico's met zich mee bij elke stap van de levenscyclus van referenties: hoe je ze opslaat, verzendt, uitwisselt en intrekt. Verschillende ernstige kwetsbaarheden maakten dat in de loop van 2025 duidelijk.

CVE-2025-6514: Command Injection via OAuth Discovery

JFrog Security Research ontdekte een kritieke kwetsbaarheid (CVSS 9.6) in mcp-remote, een populaire npm-package die als proxy diende voor OAuth-verbindingen van MCP-clients — waaronder Cursor. Het probleem? De package haalde de authorization_endpoint URL op van de MCP-server waarmee verbinding werd gemaakt en valideerde deze niet.

Een kwaadwillende serverbeheerder kon shell-commando's in die endpoint-URL injecteren. Wanneer mcp-remote de URL in een browser probeerde te openen, voerde het besturingssysteem de ingebedde commando's uit in plaats van een webpagina te laden.

Versies 0.0.5 tot en met 0.1.15 waren kwetsbaar. Meer dan 437.000 downloads. Cloudflare, Hugging Face en Auth0 verwezen allemaal naar mcp-remote in hun MCP-integratiedocumentatie. De fix is doorgevoerd in versie 0.1.16.

In de kern was deze kwetsbaarheid terug te voeren op het OAuth-vertrouwensmodel: de MCP-client vroeg aan een niet-vertrouwde server "waar moet ik de gebruiker naartoe sturen om in te loggen?" en volgde dat antwoord blindelings op. De patch voegde URL-validatie en opschoning toe voordat er gegevens aan system handlers werden doorgegeven.

Account-takeover met één klik in Remote MCP-servers

Obsidian Security publiceerde een reeks kwetsbaarheden voor account-takeover met één klik in productie-MCP-servers van bekende organisaties. De gemeenschappelijke deler: de meeste MCP-servers fungeren ook als OAuth-proxy — ze ontvangen een autorisatiecode van Cursor en wisselen die bij de bovenliggende dienst in voor tokens.

Het probleem was structureel van aard. Deze servers slaagden er niet in om OAuth-stateparameters te koppelen aan gebruikerssessies. Ook dweongen ze toestemming niet correct af. Een kwaadwillende kon een link maken die een autorisatiecode doorstuurde naar een redirect-URI onder controle van de aanvaller.

Obsidian diende de rapporten in tussen juli en augustus 2025. Leveranciers hebben de problemen in september gepatcht. De update van de MCP-specificatie van november 2025 voegde expliciete beveiligingsrichtlijnen toe voor deze specifieke aanvalspatronen. Opmerkelijk: slechts 3 van de 78 door Obsidian geteste MCP-autorisatieservers ondersteunden op dat moment daadwerkelijk CIMD. De adoptie van nieuwere functies uit de specificatie verloopt traag.

MCP Client-kwetsbaarheden via OAuth-flows

Obsidian signaleerde ook kritieke bugs in MCP-clients zelf — Gemini-CLI, VS Code, Windsurf en Cherry Studio bevatten allemaal fouten (CVE-2025-54074 en drie gerelateerde CVE's). De categorie van de kwetsbaarheid was Remote Code Execution door onzorgvuldige verwerking van autorisatie-URL's.

Wanneer een MCP-client een speciaal geprepareerde authorization_endpoint opende via de URL-handler van het systeem, kon een aanvaller willekeurige OS-commando's uitvoeren op de machine van de ontwikkelaar. De MCP-autorisatiespecificatie beperkt URL-schema's niet, waardoor file://, javascript: of platform-specifieke schema's konden worden verwerkt als de client geen validatie uitvoerde.

Referenties in platte tekst in mcp.json

Het meest voorkomende risico heeft geen CVE-nummer nodig. Elke API-sleutel die je in mcp.json zet, staat in platte tekst op je bestandssysteem. Als dat bestand in een projectmap terechtkomt en iemand commit het naar Git, lekt de referentie naar elke bijdrager — en mogelijk naar iedereen op het internet als het een openbare repository betreft. Omgevingsvariabelen vereisen tenminste shell-toegang. Maar mcp.json is een geconfigureerd bestand in versiebeheer dat ontwikkelaars regelmatig delen, zonder erbij stil te staan.

Hoe de MCP Auth-specificatie evolueerde

De MCP-autorisatiespecificatie heeft in 2025 drie grote herzieningen ondergaan. Elke herziening pakte concrete tekortkomingen uit de vorige versie aan.

De herziening van juni 2025 was de belangrijkste stap. Vóór die wijziging moest elke MCP-serverontwikkelaar zijn eigen autorisatie-endpoints bouwen. Dat dwong in feite elke maker van een server om een OAuth-implementator te worden — een slecht idee met het oog op beveiliging. De bijgewerkte specificatie verplaatste het uitgeven van tokens naar toegewijde identity providers (Okta, Auth0, Azure AD), wat overeenkomt met de wijze waarop enterprise-authenticatie al jaren werkt.

November 2025 pakte clientregistratie direct aan. DCR zorgde voor problemen omdat de meeste enterprise-autorisatieservers dit niet standaard inschakelen. CIMD omzeilt dat probleem: elke client publiceert een metadatadocument op een bekende URL, en autorisatieservers nemen beslissingen over vertrouwen louter op basis van het domein. Schoner, praktischer en geschikter voor streng beveiligde enterprise-omgevingen.

Enterprise-authenticatie met een MCP Gateway

Een enkele ontwikkelaar kan een handvol API-sleutels zonder veel moeite beheren. Voor een team ligt dat anders. Tien ontwikkelaars die elk vijf MCP-servers gebruiken, creëren vijftig afzonderlijke configuraties van referenties — zonder centraal zicht op wie waar toegang toe heeft, zonder geautomatiseerde sleutelrotatie en zonder audit trail.

Een MCP Gateway brengt dat allemaal samen op één plek. De MCP Gateway van TrueFoundry ondersteunt drie authenticatiemethoden bij het registreren van bovenliggende MCP-servers:

• No Auth: Voor demo-omgevingen of openbare API's. Niet geschikt voor productie.
• Static Header Auth: Voor servers die API-sleutels of statische tokens gebruiken. De gateway slaat de referentie centraal op en injecteert deze in elk uitgaand verzoek.
• OAuth2 en DCR: Voor servers die OAuth implementeren. De gateway doorloopt de volledige OAuth-flow, slaat tokens per gebruiker op en vernieuwt deze automatisch voordat ze verlopen.

Het operationele model lijkt op single sign-on, maar dan voor MCP. Ontwikkelaars authenticeren zich eenmalig bij TrueFoundry — via een Personal Access Token (PAT) of via de identity provider van hun organisatie (Okta, Azure AD). De gateway koppelt die identiteit aan de juiste onderliggende referentie voor elke MCP-server. Individuele ontwikkelaars komen nooit rechtstreeks in aanraking met een OAuth-token.

Aan de beheerderszijde organiseer je servers in MCP Server Groups en wijs je toegang toe op basis van team of rol. Een junior ontwikkelaar krijgt bijvoorbeeld alleen-lezen toegang tot GitHub. Een senior engineer krijgt volledige GitHub-toegang én schrijftoegang tot JIRA. De gateway dwingt die grenzen af op protocolniveau — niet via vrijblijvende configuratiebestanden.

Hier is een gedetailleerde handleiding voor het instellen van Okta OAuth2-authenticatie met MCP-servers via de gateway, inclusief het inrichten van de autorisatieserver, scopebeheer en de configuratie voor het vernieuwen van tokens.

Belangrijkste criteria voor het evalueren van een Gateway

Criterium	Wat moet je evalueren?	Prioriteit	TrueFoundry
Latency	Voegt <10ms p95 overhead toe voor time-to-first-token?	Must Have	✅ Ondersteund
Data Residency	Bewaart logs binnen je eigen regio (EU/US)?	Afhankelijk van use case	✅ Ondersteund
Latency-Based Routing	Schakelt automatisch om op basis van real-time latency/storingen?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Roteer of trek sleutels in zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Roteer of trek sleutels in zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Roteer of trek sleutels in zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Roteer of trek sleutels in zonder downtime?	Must Have	✅ Ondersteund
Sleutelrotatie & Intrekking	Roteer of trek sleutels in zonder downtime?	Must Have	✅ Ondersteund

MCP Gateway Evaluatie-checkliste

Een praktische gids voor platform- & infra-teams

Best practices voor MCP-authenticatie in Cursor

• Commit nooit geheimen naar mcp.json. Gebruik de ${env:VAR} referentiesyntaxis voor stdio-servers. Kies voor OAuth op remote servers. Als statische headers de enige optie zijn, verwijs dan ook daarin naar omgevingsvariabelen.
• Geef de voorkeur aan OAuth boven statische tokens voor remote verbindingen. OAuth-tokens verlopen. Je kunt ze scopen. Je kunt ze intrekken. Statische tokens bieden deze mogelijkheden niet.
• Pin je mcp-remote versie als je daarvan afhankelijk bent. CVE-2025-6514 heeft aangetoond dat één ongepatchte OAuth-proxy je gehele ontwikkelomgeving in gevaar kan brengen. Gebruik npx -y mcp-remote@0.1.16 of hoger — gebruik nooit @latest in productie.
• Beperk token-scopes strikt. Wanneer Cursor je door een OAuth-flow leidt, verleen dan de minimale machtigingen. Alleen-lezen voor code search. Verleen pas schrijftoegang als de agent daadwerkelijk issues moet aanmaken of PR's moet mergen.
• Controleer je verbonden servers regelmatig. Ga naar Cursor Settings → Tools & MCP en controleer wat actief is. Verwijder alles wat je niet meer gebruikt. Elke verbonden server vertegenwoordigt een actieve referentie in het geheugen.
• Houd Cursor up-to-date. Elke release bevat verbeteringen voor OAuth-afhandeling en beveiligingspatches. Een verouderde Cursor-versie betekent dat er verouderde authenticatiecode op je machine draait.

Conclusie

MCP-authenticatie in Cursor kent verschillende niveaus — van een API-sleutel in platte tekst in een JSON-bestand tot een volledige OAuth 2.1-flow met PKCE, dynamische registratie en automatische tokenvernieuwing. Het kiezen van de juiste methode hangt af van het implementatiemodel van de server en de mate waarin je beveiliging prioriteert.

Voor lokale ontwikkeling houden omgevingsvariabelen in combinatie met de ${env:VAR} syntaxis de referenties buiten versiebeheer. Voor remote diensten neemt OAuth het handmatige tokenbeheer volledig uit handen. En voor teams of enterprise-organisaties centraliseert een MCP Gateway zoals die van TrueFoundry de opslag van referenties, dwingt deze rolgebaseerde toegang af en biedt deze een volledige audit trail over elke MCP-verbinding.

Ontdek TrueFoundry's MCP Gateway of boek een demo om gecentraliseerde MCP-authenticatie in actie te zien.

Veelgestelde vragen

Welke authenticatiemethoden ondersteunt Cursor voor MCP-servers?

Cursor ondersteunt er drie: omgevingsvariabelen die worden geïnjecteerd in lokale stdio-serverprocessen, statische HTTP-headers (Bearer-tokens of API-sleutels) voor remote servers, en OAuth 2.1 met PKCE voor remote servers die de MCP-autorisatiespecificatie volgen. OAuth-ondersteuning is beschikbaar sinds Cursor v1.0, uitgebracht in juni 2025.

Hoe werkt OAuth voor MCP in Cursor?

Wanneer je een remote MCP-server toevoegt die OAuth vereist, volgt Cursor de MCP-autorisatiespecificatie. Het zoekt de autorisatieserver via Protected Resource Metadata (RFC 9728), registreert zichzelf als client, opent je browser zodat je kunt inloggen en machtigingen verlenen, en wisselt vervolgens de autorisatiecode in voor tokens middels PKCE. Cursor slaat de tokens veilig op en vernieuwt deze zelfstandig wanneer ze dreigen te verlopen.

Is het veilig om API-sleutels op te slaan in mcp.json?

Het rechtstreeks plaatsen van API-sleutels in mcp.json betekent dat referenties in platte tekst op de schijf staan. Als dat bestand in versiebeheer terechtkomt, lekt de sleutel. Gebruik in plaats daarvan de ${env:VARIABLE_NAME} referentiesyntaxis — hiermee worden waarden tijdens runtime uit de systeemomgeving opgehaald. Gebruik voor remote servers bij voorkeur OAuth, waarmee statische referenties volledig overbodig worden.

Wat hield de kwetsbaarheid in mcp-remote in?

CVE-2025-6514 was een kritieke command injection-bug (CVSS 9.6) in het mcp-remote npm-package, die van invloed was op versies 0.0.5 tot en met 0.1.15. JFrog Security Research ontdekte dat het package OAuth-autorisatie-endpoint-URL's doorstuurde naar system handlers zonder enige opschoning (sanitization). Een kwaadwillende MCP server kon een URL construeren die willekeurige OS-commando's uitvoerde op de machine van de ontwikkelaar. Versie 0.1.16 bevatte de fix.

Hoe beheren enterprises MCP-authenticatie op schaal?

Met een MCP Gateway die het volledige beheer van authenticatiegegevens overneemt. De gateway van TrueFoundry slaat OAuth-tokens op per gebruiker en ververst deze, koppelt organisatie-identiteiten aan downstream MCP-credentials en dwingt role-based access control (RBAC)-beleid af. Ontwikkelaars loggen één keer in en hoeven nooit meer bezig te zijn met individuele MCP server-tokens.

Ondersteunt Cursor CIMD voor OAuth client-registratie?

Begin 2026 nog niet. Cursor leunt voor zijn OAuth-flows nog steeds op Dynamic Client Registration (DCR). De MCP-specificatie van november 2025 introduceerde CIMD als de geprefereerde registratiemethode, maar berichten op het communityforum uit januari 2026 suggereren dat de functie nog niet is uitgebracht. In de tussentijd blijft DCR prima werken voor de meeste MCP servers met OAuth-ondersteuning.