Gids voor MCP-authenticatie in Claude Code 2026

Wat is MCP?

MCP (Model Context Protocol) is een open standaard ontwikkeld door Anthropic waarmee Claude Code op een gestructureerde manier kan communiceren met externe systemen.
In plaats van tool-logica in de prompt te proppen, creëert MCP een duidelijke middleware-laag. Claude roept de tool aan in een standaardformaat. De MCP-server ontvangt het verzoek en stuurt dit door naar het werkelijke systeem erachter, zoals een database, interne API, cloudservice of ticketbeheersysteem.

Je kunt de MCP-server zien als een adapterlaag. De ene kant is Claude Code. De andere kant is je fysieke infrastructuur. Het helpt beide kanten elkaar te begrijpen zonder dat alles vanaf nul herschreven hoeft te worden bij elke nieuwe integratie.

Zonder MCP reageerde Claude Code alleen op tekst. Met MCP begint het te interageren met het echte systeem. En vanaf dat moment is het niet langer alleen "AI die voor de lol antwoordt".

Waarom MCP-authenticatie belangrijk is

Nu MCP populairder wordt, zie ik veel mensen Claude Code gebruiken om direct verbinding te maken met interne systemen. Sommigen voeren alleen API-tests uit. Anderen maken direct verbinding met services die op AWS draaien met strikte IAM-regels.

Het probleem is: zodra Claude de tool kan aanroepen, vertegenwoordigt het een bepaalde identiteit binnen je systeem.

Als de authenticatieconfiguratie te ruim is, is het risico niet direct zichtbaar. Het is verraderlijk. Zoals toen ik een CloudFront-configuratie debugde. Het was slechts een ogenschijnlijk onschuldige regel voor het doorsturen van headers. Geen 500-fouten, geen downtime. Maar in werkelijkheid was de toegangsgrens verder uitgebreid dan verwacht. Je moet de logs zorgvuldig onderzoeken om het probleem te vinden.

Hetzelfde geldt voor MCP. Als je de verkeerde authenticatiemethode kiest, kun je onbedoeld:

• Je langetermijn-API-sleutel blootstellen
• Toegangssleutels verspreiden onder meerdere verschillende gebruikers
• Claude meer rechten geven dan strikt noodzakelijk.

Verbinding maken met een productiedatabase of financieel systeem op AWS is dan geen klein probleem meer

Het kiezen van de juiste authenticatiemethode gaat daarom niet alleen om "de verbinding werkend krijgen". Het kan de veiligheid en consistentie van het gehele systeem erachter bepalen.

Waarom is authenticatie het eerste waar je over na moet denken?

Deze externe tools zijn verre van "onschadelijk". Ze kunnen broncode, klantgegevens, productiedata en interne tickets bevatten. Maar wanneer Claude verbinding maakt via MCP, leest het niet zomaar voor de lol. Het fungeert als een geverifieerde identiteit diep in je systeem. Als de authenticatie zwak is, kun je worden aangevallen. Er is geen complexe aanval voor nodig. Eén gelekte API-sleutel is genoeg om de zaken heel snel uit de hand te laten lopen.

De situatie waar ik tegenaan liep was vergelijkbaar. De service biedt slechts één token voor zowel de ontwikkel- als de productieomgeving. Alles zou in orde zijn geweest als die tokeninformatie niet was gelekt tijdens het testen van een repository. Daarom moeten we de inloggegevens voor zowel de productie- als de ontwikkelomgeving wijzigen om problemen te voorkomen zodra ze worden ontdekt. Het systeem zelf is dus niet het probleem; het cruciale punt ligt in hoe je machtigingen beheert. Autorisatie is niet zomaar een extraatje; het bepaalt wat Claude binnen zijn toegestane bereik kan doen, waardoor veiligheidsrisico's worden voorkomen.

Waar gaat dit artikel over?

Claude Code ondersteunt verschillende authenticatiemethoden. Bijvoorbeeld:

• API-sleutel
• Bearer-token
• OAuth
• AWS-referentie (toegangssleutel of rol aannemen)

Op het eerste gezicht is het verwarrend. Elke methode bestaat om een eigen reden. Er is geen "juiste manier voor alle gevallen".

Het kiezen van de verkeerde methode kan leiden tot:

• Blootstelling van inloggegevens
• De noodzaak om halverwege opnieuw te configureren
• Tijdverlies voor het team bij het herstellen van workflows

Ik heb ooit een MCP-server geconfigureerd die achter een API Gateway op AWS draaide.

Aanvankelijk gebruikte ik toegangssleutels voor de lange termijn om de toegang te versnellen. Ik realiseerde me echter dat dit niet ideaal was in vergelijking met het delen van sleutels met meerdere testers voor eenvoudige toegang. Uiteindelijk ben ik overgestapt op het aannemen van rollen om machtigingen duidelijker te definiëren.

Dit artikel gaat dieper in op elk punt en legt uit wanneer je welke methode moet gebruiken. Het doel is om je te helpen vanaf het begin de juiste keuze te maken, zodat toekomstige aanpassingen niet nodig zijn.

Claude Code installeren

Als je Claude Code nog niet hebt geïnstalleerd, kun je het snel instellen.

macOS, Linux, WSL:

curl -fsSL https://claude.ai/install.sh | bash

Windows PowerShell:

irm https://claude.ai/install.ps1 | iex

Alleen voor macOS

brew install --cask claude-code

Ga nu door naar de volgende secties over authenticatiebeveiliging

Beveiliging definiëren in een CLI-omgeving

Wanneer mensen een CLI op hun lokale machine gebruiken, denken ze vaak alleen aan HTTPS. Het grotere probleem is echter hoe je je inloggegevens beheert.

HTTPS beschermt gegevens alleen tijdens de overdracht. Het helpt niet als het token op je machine wordt blootgesteld. In een CLI-omgeving zijn dit de belangrijkste problemen:

• Waar sla je de sleutel op?
• Hoe lang is het token geldig?
• Wie kan het gebruiken?

Lage beveiliging is wanneer je een API-sleutel voor de lange termijn in een configuratiebestand in platte tekst laat staan. Als dat bestand per ongeluk in de repository wordt geplaatst, is het mis. Die sleutel is dan in feite onbeheersbaar. En omdat het een sleutel voor de lange termijn is, moet je deze handmatig roteren.

Ik kwam ooit in een vergelijkbare situatie terecht tijdens het debuggen van een omgevingsprobleem met ECS. Ik gebruikte de Amazon ECS MCP-server met een toegangssleutel en een geheime sleutel. Daarna vergat ik die inloggegevens. Een paar dagen later vroeg ik Claude om wat problemen in een andere omgeving te onderzoeken, maar het systeem gebruikte nog steeds de oude inloggegevens, waardoor het uiteindelijk veel acties uitvoerde in de productieomgeving.

Hoge beveiliging werkt anders. Je gebruikt tokens voor de korte termijn, verwijst ernaar via omgevingsvariabelen of gebruikt authenticatiemechanismen op serviceniveau, zoals IAM-rollen. Wanneer je bijvoorbeeld AWS SSO gebruikt, hebben tokens een duidelijke vervaldatum. Na het verlopen moet je opnieuw inloggen. Als de machine wordt gecompromitteerd, heeft de aanvaller slechts een zeer kort tijdsvenster om actie te ondernemen. Deze methode is niet perfect, maar beperkt de schade als er iets misgaat.

Hieronder staan vier veelgebruikte methoden voor het configureren van authenticatie voor MCP-servers in Claude Code. Elke methode is geschikt voor een andere context.

1. Statische HTTP-headers (API-sleutels & Bearer-tokens)

Dit is de makkelijkste methode om mee te beginnen. Deze manier werkt goed met veel externe diensten die gebruikmaken van API-sleutels voor de lange termijn of Private Access Tokens (PAT's).

Configuratie via de opdrachtregel

Als je snel een MCP-server met een authenticatieheader wilt toevoegen, gebruik dan gewoon “claude mcp add” en geef “--header”

# Add a weather service MCP server with Bearer Token authentication
claude mcp add weather-service \
    --transport http \
    --header "Authorization: Bearer secret-token-123" \
    https://api.weather-data.com/mcp

Zodra het proces is voltooid, schrijft Claude automatisch de configuratie voor je. Handmatige stappen zijn niet nodig. “Claude/settings.json”. Deze methode is erg handig om snel een externe service te controleren.

Ik gebruik het vaak wanneer ik een API moet testen voordat ik deze officieel in het systeem integreer. Onthoud één ding: plak het daadwerkelijke token niet in het commando en commit vervolgens je shell-geschiedenis ergens. Dat gebeurt vaker dan je denkt.

Configuratiebestand (.claude/settings.json)

Als je de token-code niet als platte tekst in het bestand wilt zetten, kun je een omgevingsvariabele gebruiken.

Claude leest “${ENV_VAR}” en vervangt dit door de werkelijke waarde wanneer de CLI start.

Bijvoorbeeld:

{
  "mcpServers": {
    "data-tool": {
      "url": "https://api.myservice.com/mcp",
      "type": "http",
      "headers": {
        "Authorization": "Bearer ${APP_API_TOKEN}",
        "X-Org-Id": "org-888"
      }
    }
  }
}

Deze methode is veiliger dan het token direct in het bestand te schrijven. Je hoeft alleen de omgevingsvariabele te exporteren voordat je Claude uitvoert.

Ik zag ooit dat een intern repository per ongeluk een token naar de configuratie committe. Aanvankelijk dacht ik dat het een privé-repository was, dus dat het geen kwaad kon. Vervolgens werd de repository gedeeld met een ander team voor tests. Het productie-token was ook inbegrepen. Het gebruik van omgevingsvariabelen lost niet alle risico's op, maar het verkleint in ieder geval de kans op het per ongeluk blootstellen van sleutels bij het committen.

Voordelen:

• Eenvoudig te configureren.
• Geschikt voor snelle integratie met externe services.

Nadelen:

• Het token is nog steeds van een langetermijntype.
• Als het uitlekt, moet je het handmatig roteren.

2.1 AWS MCP-inloggegevens

2.1 Toegangssleutel en geheime sleutel (voor AWS-gehoste MCP-servers)

Als je MCP-server zich in AWS bevindt, is dit veel praktischer. Je kunt de bestaande AWS-inloggegevens op je machine gebruiken. Dit wordt doorgaans geconfigureerd via AWS configure of AWS SSO. Claude neemt variabelen over zoals:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN
• AWS_PROFILE

Dit is zeer nuttig wanneer de MCP-server achter een API Gateway draait, of wanneer de backend op Lambda of ECS staat en IAM-authenticatie is ingeschakeld. 

Bijvoorbeeld door een MCP-proxy te configureren om verzoeken te ondertekenen met Signature V4:

{
  "mcpServers": {
    "cloud-logger": {
      "command": "node",
      "args": ["/path/to/aws-mcp-proxy.js"],
      "env": {
        "AWS_PROFILE": "my-dev-profile",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://my-mcp-service.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

Of, eenvoudiger nog, exporteer omgevingsvariabelen voordat je Claude uitvoert:

# Stel AWS-inloggegevens in voordat je Claude Code uitvoert

export AWS_PROFILE=my-dev-profile
export AWS_REGION=ap-southeast-1

# Start Claude Code — de MCP-server gebruikt deze inloggegevens claude

Claude hoeft de details van de sleutel niet te kennen. Het gebruikt alleen de AWS-context waarin je bent ingelogd.

Ik herinner me dat ik een interne MCP-server aan het debuggen was die achter een API Gateway draaide. Verzoeken gaven constant 403-fouten. Destijds dacht ik dat het een beleidskwestie was. Maar toen ontdekte ik dat het AWS SSO-certificaat op mijn machine was verlopen. Door simpelweg het commando “aws sso login” opnieuw uit te voeren, was alles opgelost. Sindsdien merk ik altijd op dat geregistreerde services de sessie moeten controleren voordat je ermee aan de slag gaat, in plaats van direct de schuld aan IAM te geven.

Voordelen:

• Tokens zijn meestal kortstondig via STS.
• Kunnen automatisch worden geroteerd.
• Hogere beveiliging dan langdurige API-sleutels.

Nadelen:

• Afhankelijk van de AWS-inlogstatus.
• Alles stopt direct zodra de sessie eindigt.

2.2. IAM-rol aannemen (Least Privilege Access)

Wanneer je AWS-inloggegevens direct gebruikt, handelt Claude onder jouw persoonlijke identiteit. Dat is handig, maar niet altijd de juiste manier. Door een rol aan te nemen, kan de MCP een aparte identiteit gebruiken. Deze identiteit dient alleen voor een specifieke machine of service. Dit is erg nuttig wanneer je een productieomgeving wilt simuleren.

Bijvoorbeeld om te testen hoe een service werkt met alleen-lezen toegang. Of wanneer de MCP-server alleen een vaste IAM-rol accepteert en individuele gebruikers niet direct toegang geeft.

Ik kwam een dergelijk geval tegen. Een interne API stond alleen toegang toe voor backend-rollen. Individuele gebruikers werden geblokkeerd. Om lokaal te testen, moest je die specifieke rol aannemen.

De workflow is vrij duidelijk:

1. Je verzoekt om een IAM-rol aan te nemen.
2. AWS STS controleert of je de toestemming hebt om sts:AssumeRole te gebruiken. Indien geldig, retourneert STS tijdelijke inloggegevens.
3. De MCP-proxy zal die tijdelijke inloggegevens gebruiken om de doelservice aan te roepen. De service ziet alleen de rol, niet jouw individuele gebruiker.

Wat ik goed vind aan deze methode is de zeer duidelijke autorisatie. Rollen hebben hun eigen beleid. Als je beperkingen wilt opleggen, kun je die in dat beleid aanpassen. Het nadeel is dat de initiële configuratie wat tijdrovend is. Als het vertrouwensbeleid (Trust policy) ook maar één regel afwijkt, zal het aannemen van de rol niet werken. En het debuggen van IAM is nooit een leuke klus.

Configuratievoorbeeld

{
  "mcpServers": {
    "finance-bot": {
      "command": "node",
      "args": ["/path/to/aws-role-mcp-proxy.js"],
      "env": {
        "ASSUME_ROLE_ARN": "arn:aws:iam::123456789012:role/mcp-finance-bot-role",
        "AWS_REGION": "ap-southeast-1",
        "MCP_ENDPOINT": "https://secure-finance.execute-api.ap-southeast-1.amazonaws.com/prod"
      }
    }
  }
}

IAM-rechten instellen om rollen aan te nemen

Om een rol aan te nemen, moet je huidige gebruiker over de juiste machtigingen beschikken. Zonder het juiste vertrouwensbeleid stopt alles onmiddellijk.

Meestal definieer ik voor het gemak een paar variabelen:

# Variabelen definiëren

export ACCOUNT_ID="123456789012"
export ROLE_NAME="mcp-finance-bot-role"
export MY_USER_ARN="arn:aws:iam::${ACCOUNT_ID}:user/developer@company.com"

# Werk het vertrouwensbeleid van de rol bij zodat je gebruiker deze kan aannemen

aws iam update-assume-role-policy \
    --role-name "${ROLE_NAME}" \
    --policy-document '{
      "Version": "2012-10-17",
      "Statement": [{
        "Effect": "Allow",
        "Principal": {"AWS": "'"${MY_USER_ARN}"'"},
        "Action": "sts:AssumeRole"
      }]
    }

Dit gedeelte doet in feite maar één ding. Het vertelt AWS dat jouw gebruiker de toestemming heeft om die rol aan te nemen.

Ik heb ooit bijna een hele middag verspild omdat ik de verkeerde ARN in het vertrouwensbeleid had staan. Het beleid dat aan de rol was gekoppeld, was correct, maar het vertrouwensbeleid stond niet toe dat de gebruiker de rol aannam. Hierdoor bleef STS een AccessDenied-foutmelding geven. Nog een punt om te onthouden:

IAM heeft een kleine vertraging. Nadat je het beleid hebt bijgewerkt, moet je soms een minuut of twee wachten voordat het effectief wordt. Raak niet in paniek als een test direct daarna nog niet werkt.

Voordelen:

• Handhaaft het principe van minimale rechten.
• Alles wat een rol kan doen, valt binnen het bijbehorende beleid.

Nadelen:

• De configuratie is wat ingewikkeld.
• Eén kleine fout is al genoeg om het niet te laten werken.

3. Ingebouwde OAuth 2.0-ondersteuning

Voor complexe externe diensten zoals GitHub, Linear of Slack is een API-sleutel niet voldoende. Deze vereisen een aanmelding via een standaard gebruikersstroom. Claude Code biedt ingebouwde OAuth-ondersteuning voor dit type MCP-servers.

Shell-commando's

Je hoeft niet je eigen inlogstroom te schrijven. Voordat je begint, kun je controleren welke servers authenticatie vereisen:

# List the MCP servers that need authentication
claude mcp list

Als je servers ziet die nog niet zijn ingelogd, voer dan simpelweg het volgende uit:

# Start the login flow for a GitLab MCP server (opens browser)
claude mcp auth gitlab-server

Interactieve commando's

Er is een handige functie: als je Claude gebruikt en een machtigingsfout tegenkomt, hoef je de sessie niet te verlaten. Je kunt direct binnen de chatsessie autoriseren. 

Voorbeeld: 

>>> Jij: Toon mijn takenlijst.

>>> Claude: Ik heb toegang nodig tot Linear.

>>> /mcp auth linear-server

Typ gewoon dat commando. Claude zal de inlogprocedure opnieuw activeren. Meestal opent de browser automatisch om de rechten te bevestigen.

Ik kwam ooit in een situatie terecht waarin het Linear-token verliep terwijl ik een issue aan het bekijken was. Claude meldde halverwege dat ik onvoldoende rechten had.

 In plaats van de CLI opnieuw op te starten, voerde ik simpelweg “/mcp auth” uit en het was geregeld. Ik kon daarna direct weer aan het werk.

Voordelen:

• Standaard OAuth-procedure.
• Tokens worden automatisch vernieuwd.
• Een vrij soepele ervaring tijdens het werken met een gebruiker.

Nadelen:

• Soms moet je toch de browser openen en opnieuw inloggen. Vooral wanneer je van computer wisselt of wanneer de inlogsessie verloopt.

Samenvatting

De keuze voor een authenticatiemethode hangt af van twee factoren:

• Waar je je inloggegevens opslaat.
• En welk probleem je probeert op te lossen.

Er is geen optie die overal het beste werkt. Alleen de optie die past bij de context. Een kleine maar belangrijke opmerking: zorg er eerst voor dat je Node.js-omgeving stabiel is. Ik ontdekte uiteindelijk dat de lokale machine de verkeerde Node-versie gebruikte. Het simpelweg wijzigen naar “nvm use” zou normaal gesproken moeten werken. Het gebruik van nvm helpt om veel onverklaarbare fouten door omgevingsverschillen te voorkomen. Onderschat dit niet. 

Snelgids: MCP-servers toevoegen in Claude Code

HTTP-transport met authenticatie-header

# HTTP-transport met authenticatie-header

claude mcp add my-server \
    --transport http \
    --header "Authorization: Bearer ${MY_TOKEN}" \
    https://my-mcp-server.com/mcp

# Stdio-transport (lokaal proces)

claude mcp add my-local-server \
    -- node /path/to/server.js

# Geconfigureerde MCP-servers weergeven

claude mcp list

# Een MCP-server verwijderen

claude mcp remove my-server

Het onthouden van deze commando's is voldoende om aan de slag te gaan. De rest draait om het kiezen van de juiste authenticatiemethode voor de juiste situatie.

Veelgestelde vragen

Hoe genereer ik een Claude Code MCP OAuth-token?

Om een Claude Code MCP OAuth-token te genereren, integreer je doorgaans met een OAuth-provider die kortstondige toegangstokens uitgeeft. Deze uiterst veilige methode helpt voorkomen dat langetermijnreferenties voor je Claude Code MCP-verbindingen direct worden blootgesteld. De specifieke stappen hangen af van de configuratie van de door jou gekozen OAuth-provider en de integratie daarvan met Claude Code.

Kan Claude Code MCP-servers benaderen?

Ja, Claude Code kan MCP-servers benaderen, waardoor interactie met externe systemen zoals databases en API's mogelijk wordt. Deze functionaliteit verandert Claude Code van een tekstgebaseerde assistent in een actieve deelnemer in je systemen. Effectieve Claude Code MCP-authenticatie is essentieel voor veilige operaties, om ongeautoriseerde toegang te voorkomen en de gegevensintegriteit binnen de Amerikaanse infrastructuur te waarborgen.

Hoe authenticeer ik Figma MCP in Claude Code?

Om Figma MCP in Claude Code te authenticeren, moet je een veilige Claude MCP-authenticatiemethode kiezen. Dit houdt doorgaans het gebruik van API-sleutels, OAuth of Bearer-tokens in, afhankelijk van de integratie van Figma en je beveiligingsbeleid. Richt je op het verlenen van minimale rechten en vermijd langetermijnsleutels om een veilige systeeminteractie te garanderen.