Leitfaden zur MCP-Authentifizierung im Claude Code 2026-Handbuch

Was ist MCP?

MCP (Model Context Protocol) ist ein von Anthropic entwickelter offener Standard, der es Claude Code ermöglicht, strukturiert mit externen Systemen zu kommunizieren.
Anstatt die Tool-Logik in die Eingabeaufforderung einzufügen, erstellt MCP eine klare Middleware-Ebene. Claude ruft das Tool in einem Standardformat auf. Der MCP-Server empfängt die Anfrage und leitet sie an das eigentliche System weiter, das dahinter steht, z. B. eine Datenbank, eine interne API, einen Cloud-Dienst oder ein Ticketverwaltungssystem.

Sie können sich den MCP-Server als Adapterschicht vorstellen. Eine Seite ist Claude Code. Die andere Seite ist Ihre physische Infrastruktur. Es hilft beiden Seiten, einander zu verstehen, ohne bei jeder Integration alles von Grund auf neu schreiben zu müssen.

Ohne MCP antwortete Claude Code nur auf Text. Mit MCP beginnt es, mit dem realen System zu interagieren. Und ab diesem Zeitpunkt geht es nicht mehr nur darum, dass „KI zum Spaß antwortet“.

Warum MCP-Authentifizierung wichtig ist

Da MCP immer beliebter wird, sehe ich, dass viele Leute Claude Code verwenden, um sich direkt mit internen Systemen zu verbinden. Manche nennen einfach API-Tests. Andere stellen mit straffem IAM eine direkte Verbindung zu Diensten her, die auf AWS ausgeführt werden.

Das Problem ist: Sobald Claude das Tool aufrufen kann, repräsentiert es eine Art Identität in Ihrem System.

Wenn die Authentifizierungskonfiguration locker ist, wird das Risiko nicht sofort angezeigt. Es ist heimtückisch. Wie beim Debuggen einer CloudFront-Konfiguration unter. Es war nur eine scheinbar harmlose Forward-Header-Regel. Keine 500 Fehler, keine Ausfallzeiten. In Wirklichkeit wurde die Zugangsgrenze jedoch stärker als erwartet erweitert. Sie müssen die Protokolle sorgfältig prüfen, um das Problem zu finden.

Das Gleiche gilt für MCP. Wenn Sie die falsche Authentifizierungsmethode wählen, könnten Sie versehentlich:

• Stellen Sie Ihren langfristigen API-Schlüssel bereit
• Verteilen Sie Zugriffsschlüssel an mehrere verschiedene Benutzer
• Gewähren Sie Claude zu viele Privilegien als nötig.

Die Verbindung zu einer Fertigungsdatenbank oder einem Finanzsystem auf AWS ist kein unbedeutendes Problem mehr

Daher geht es bei der Auswahl der richtigen Authentifizierungsmethode nicht nur darum, „die Verbindung zum Laufen zu bringen“. Sie kann die Sicherheit und Konsistenz des gesamten Systems bestimmen, das dahinter steht.

Warum ist die Authentifizierung das Erste, was zu berücksichtigen ist?

Diese externen Tools sind alles andere als „harmlos“. Sie können Quellcode, Kundendatensätze, Produktionsdaten und interne Tickets enthalten. Aber wenn Claude sich über MCP verbindet, liest er nicht nur zum Spaß. Es fungiert tief in Ihrem System als verifizierte Identität. Wenn die Authentifizierung schwach ist, könnten Sie angegriffen werden. Es ist kein komplexer Angriff erforderlich. Ein durchgesickerter API-Schlüssel genügt, damit die Dinge sehr schnell den Bach runtergehen.

Die Situation, auf die ich gestoßen bin, war ähnlich. Der Service bietet nur ein einziges Token sowohl für die Entwicklungs- als auch für die Produktionsumgebung. Alles wäre in Ordnung, wenn diese Token-Informationen beim Testen eines Repositorys nicht durchgesickert wären. Daher müssen wir die Anmeldeinformationen sowohl für die Produktions- als auch für die Entwicklungsumgebung ändern, um zu vermeiden, dass Probleme auftreten, sobald sie entdeckt werden. Das System selbst ist also nicht das Problem; das entscheidende Problem liegt in der Art und Weise, wie Sie die Berechtigungen verwalten. Die Autorisierung ist nicht nur ein Zusatz; sie bestimmt, was Claude innerhalb des erlaubten Umfangs tun kann, und verhindert so Sicherheitsrisiken.

Worum geht es in diesem Artikel?

Claude Code unterstützt verschiedene Authentifizierungsmethoden. Zum Beispiel:

• API-Schlüssel
• Inhabermarke
• OAuth
• AWS-Anmeldeinformationen (Zugriffsschlüssel oder Rolle übernehmen)

Auf den ersten Blick ist es verwirrend. Jede Methode existiert aus ihrem eigenen Grund. Es gibt keinen „richtigen Weg für alle Fälle“.

Die Wahl der falschen Methode kann zu Folgendem führen:

• Gefährdung durch Zugangsdaten
• Muss auf halbem Weg neu konfiguriert werden
• Team verschwendet Zeit mit der Korrektur von Arbeitsabläufen

Ich habe einmal einen MCP-Server konfiguriert, der hinter einem API-Gateway auf AWS läuft.

Anfangs habe ich Langzeitzugriffsschlüssel verwendet, um den Zugriff zu beschleunigen. Mir wurde jedoch klar, dass dies nicht ideal war, verglichen mit der gemeinsamen Nutzung von Schlüsseln mit mehreren Testern, um den Zugriff zu erleichtern. Letztlich wechselte ich zu rollenbasierten Annahmen, um Berechtigungen klarer zu definieren.

In diesem Artikel wird auf jeden Punkt eingegangen und erklärt, wann die einzelnen Methoden angewendet werden müssen. Ziel ist es, Ihnen zu helfen, von Anfang an die richtige Wahl zu treffen und zukünftige Änderungen zu vermeiden.

Installation von Claude Code

Wenn Sie Claude Code noch nicht installiert haben, können Sie es schnell einrichten.

macOS, Linux, WSL:

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

Windows PowerShell:

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

Nur macOS

brew install --cask claude-code

Fahren Sie nun mit den nächsten Abschnitten über die Authentifizierungssicherheit fort.

Definition von Sicherheit in einer CLI-Umgebung

Wenn eine CLI auf einem lokalen Computer ausgeführt wird, denken viele Leute nur an HTTPS. Tatsächlich liegt das größere Problem darin, wie Sie Ihre Anmeldeinformationen verwalten.

HTTPS schützt Daten nur während der Übertragung. Es hilft nicht, wenn das Token auf Ihrem Computer verfügbar ist. In einer CLI-Umgebung sind die Hauptprobleme:

• Wo bewahrst du den Schlüssel auf?
• Wie lange ist das Token gültig?
• Wer kann es benutzen?

Niedrige Sicherheit ist, wenn Sie einen langfristigen API-Schlüssel in einer Klartext-Konfigurationsdatei hinterlassen. Wenn diese Datei versehentlich in das Repository übertragen wird, ist es vorbei. Dieser Schlüssel ist praktisch außer Kontrolle geraten. Und weil es sich um einen Langzeitschlüssel handelt, müssen Sie ihn manuell drehen.

Ich bin einmal beim Debuggen eines Umgebungsproblems mit ECS auf eine ähnliche Situation gestoßen. Ich habe den Amazon ECS MCP Server mit einem Zugriffsschlüssel und einem geheimen Schlüssel verwendet. Danach habe ich diese Anmeldeinformationen vergessen. Ein paar Tage später bat ich Claude, einige Probleme in einer anderen Umgebung zu untersuchen, aber es wurden immer noch die alten Anmeldeinformationen verwendet, sodass es letztendlich viele Aktionen in der Produktionsumgebung durchführte.

Hohe Sicherheit ist anders. Sie verwenden kurzfristige Token. Oder Referenzierung über Umgebungsvariablen. Oder mithilfe von Authentifizierungsmechanismen auf Serviceebene wie IAM-Rollen. Wenn Sie beispielsweise AWS SSO verwenden, haben Token ein klares Ablaufdatum. Nach Ablauf müssen Sie sich erneut anmelden. Wenn der Computer kompromittiert ist, hat der Angreifer nur ein sehr kurzes Zeitfenster, um etwas zu tun. Diese Methode ist nicht perfekt. Aber es minimiert den Schaden, wenn etwas schief geht.

Im Folgenden finden Sie vier gängige Authentifizierungskonfigurationsmethoden für MCP-Server in Claude Code. Jede Methode ist für einen anderen Kontext geeignet.

1. Statische HTTP-Header (API-Schlüssel und Bearer-Token)

Dies ist die einfachste Methode, um loszulegen. Diese Methode funktioniert gut mit vielen Diensten von Drittanbietern, die langfristige API-Schlüssel oder Private Access Tokens (PATs) verwenden.

Konfiguration über die Befehlszeile

Wenn Sie schnell einen MCP-Server mit einem Authentifizierungsheader hinzufügen möchten, verwenden Sie einfach“claude mcp hinzufügen“ und pass „--Kopfzeile“

# 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

Wenn der Vorgang abgeschlossen ist, schreibt Claude die Konfiguration automatisch für Sie. Es sind keine manuellen Schritte erforderlich. “Klausel /settings.json“. Diese Methode ist sehr praktisch, um einen externen Dienst schnell zu überprüfen.

Ich verwende es oft, wenn ich eine API testen muss, bevor ich sie offiziell in das System integriere. Denken Sie nur an eines: Fügen Sie nicht das eigentliche Token in den Befehl ein und übertragen Sie dann den Shell-Verlauf irgendwo. Das passiert öfter als du denkst.

Konfigurationsdatei (.claude/settings.json)

Wenn Sie den Token-Code nicht als Klartext in die Datei einfügen möchten, können Sie eine Umgebungsvariable verwenden.

Claude wird lesen“$ {ENV_VAR}“ und ersetzen Sie ihn durch den tatsächlichen Wert, wenn die CLI startet.

Zum Beispiel:

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

Diese Methode ist sicherer, als das Token direkt in die Datei zu schreiben. Sie müssen nur die Umgebungsvariable exportieren, bevor Sie Claude ausführen.

Ich habe einmal gesehen, dass ein internes Repository versehentlich ein Token an die Konfiguration übergeben hat. Anfangs dachte ich, es wäre ein privates Repository, also war es in Ordnung. Dann wurde das Repository zum Testen mit einem anderen Team geteilt. Das Produktionstoken war ebenfalls enthalten. Die Verwendung von Umgebungsvariablen löst nicht alle Risiken. Aber zumindest reduziert es die Wahrscheinlichkeit, dass bei einer irrtümlichen Begehung ein entscheidendes Risiko entsteht.

Vorteile:

• Einfach zu konfigurieren.
• Geeignet für die schnelle Integration mit externen Diensten.

Nachteile:

• Das Token ist immer noch ein langfristiger Typ.
• Wenn es belichtet ist, müssen Sie es manuell drehen.

2.1 AWS-MCP-Anmeldeinformationen

2.1 Zugriffsschlüssel und geheimer Schlüssel (für AWS-gehostete MCP-Server)

Wenn sich Ihr MCP-Server bei AWS befindet, ist dies viel praktischer. Sie können die vorhandenen AWS-Anmeldeinformationen auf Ihrem Computer verwenden. In der Regel wird dies über AWS Configure oder AWS SSO konfiguriert. Claude wird Variablen erben wie:

• AWS_ACCESS_KEY_ID
• AWS_GEHEIMER_ACCESS_KEY
• AWS_SITZUNGSTOKEN
• AWS_PROFIL

Dies ist sehr verfügbar, wenn der MCP-Server hinter einem API-Gateway läuft. Oder wenn das Backend auf Lambda oder ECS läuft und die IAM-Authentifizierung aktiviert ist.

Zum Beispiel die Konfiguration eines MCP-Proxys zum Signieren von Anfragen mit 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"
      }
    }
  }
}

Oder, einfacher gesagt, exportiere Umgebungsvariablen, bevor du Claude ausführst:

# Legen Sie AWS-Anmeldeinformationen fest, bevor Sie Claude Code ausführen

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

# Claude Code starten — der MCP-Server verwendet diese Zugangsdaten Claude

Claude muss die wichtigsten Details nicht kennen. Es verwendet nur den AWS-Kontext, in dem Sie angemeldet sind.

Ich erinnere mich an das Debuggen eines internen MCP-Servers, der hinter einem API-Gateway lief. Anfragen gaben durchweg 403-Fehler zurück. Zu der Zeit dachte ich, es handele sich um ein politisches Problem. Aber dann stellte ich fest, dass das AWS-SSO-Zertifikat auf meinem Computer abgelaufen war. Einfach das ausführen“als SSO-Anmeldung“ Befehl hat wieder alles repariert. Seitdem habe ich immer darauf hingewiesen, dass registrierte Dienste die Sitzung überprüfen müssen, bevor sie an ihnen arbeiten, anstatt IAM die Schuld zu geben.

Vorteile:

• Tokens sind in der Regel über STS kurzfristig verfügbar.
• Kann automatisch gedreht werden.
• Höhere Sicherheit als langfristige API-Schlüssel.

Nachteile:

• Abhängig vom AWS-Anmeldestatus.
• Alles stoppt sofort, sobald die Sitzung beendet ist.

2.2. Übernahme der IAM-Rolle (Zugriff mit den geringsten Rechten)

Wenn Sie AWS-Anmeldeinformationen direkt verwenden, handelt Claude unter Ihrer persönlichen Identität. Das ist praktisch, aber nicht immer der richtige Weg. Angenommen, eine Rolle ermöglicht es dem MCP, eine separate Identität zu verwenden. Diese Identität dient nur einer bestimmten Maschine oder einem bestimmten Dienst. Dies ist sehr nützlich, wenn Sie die Produktion simulieren möchten.

Testen Sie beispielsweise, wie ein Dienst mit schreibgeschütztem Zugriff funktioniert. Oder wenn der MCP-Server nur eine feste IAM-Rolle akzeptiert. Es erlaubt einzelnen Benutzern nicht, es direkt aufzurufen.

Ich bin auf einen Fall wie diesen gestoßen. Eine interne API erlaubte nur Backend-Rollen, darauf zuzugreifen. Einzelne Benutzer wurden blockiert. Um lokal zu testen, mussten Sie diese spezielle Rolle übernehmen.

Der Arbeitsablauf ist ziemlich klar:

1. Sie beantragen die Übernahme einer IAM-Rolle.
2. AWS STS prüft, ob Sie die Erlaubnis haben, sts:AssumeRole zu verwenden. Falls gültig, gibt STS temporäre Anmeldeinformationen zurück.
3. Das MCP-Proxy verwendet diese temporären Anmeldeinformationen, um den Zieldienst aufzurufen. Der Dienst sieht nur die Rolle, nicht Ihren individuellen Benutzer.

Was mir an dieser Methode gefällt, sind die sehr klaren Berechtigungen. Rollen haben ihre eigenen Richtlinien. Wenn Sie Einschränkungen auferlegen möchten, können Sie diese in dieser Richtlinie anpassen. Der Nachteil ist, dass die Erstkonfiguration etwas zeitaufwändig ist. Wenn die Vertrauensrichtlinie auch nur um eine Zeile falsch ist, funktioniert die Annahme nicht. Und das Debuggen von IAM macht nie Spaß.

Beispiel für eine Konfiguration

{
  "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-Berechtigungen einrichten, um Rollen zu übernehmen

Um eine Rolle anzunehmen, muss Ihr aktueller Benutzer über diese Berechtigung verfügen. Ohne die richtige Vertrauensrichtlinie wird alles sofort beendet.

Normalerweise definiere ich der Einfachheit halber ein paar Variablen:

# Variablen definieren

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

# Aktualisieren Sie die Vertrauensrichtlinie der Rolle, damit Ihr Benutzer sie übernehmen kann

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"
      }]
    }

Dieser Abschnitt macht im Wesentlichen nur eine Sache. Er teilt AWS mit, dass Ihr Benutzer diese Rolle übernehmen darf.

Ich habe einmal fast einen ganzen Nachmittag verschwendet, nur weil mir der richtige ARN in der Vertrauensrichtlinie gefehlt hat. Die der Rolle zugeordnete Richtlinie war korrekt. Die Vertrauensrichtlinie erlaubte dem Benutzer jedoch nicht, davon auszugehen. Infolgedessen gab STS immer wieder einen AccessDenied-Fehler zurück. Ein weiterer Punkt, an den Sie sich erinnern sollten:

IAM hat eine kleine Verzögerung. Nach der Aktualisierung der Richtlinie müssen Sie möglicherweise ein oder zwei Minuten warten, bis sie wirksam wird. Wenn das Testen sofort immer noch fehlschlägt, geraten Sie nicht in Panik.

Vorteile:

• Behält das Prinzip der Mindestberechtigungen bei.
• Alles, was eine Rolle tun kann, ist Teil ihrer Politik.

Nachteile:

• Die Konfiguration ist etwas kompliziert.
• Nur ein kleiner Fehler und es wird nicht funktionieren.

3. Integrierte OAuth 2.0-Unterstützung

Für komplexe Dienste von Drittanbietern wie GitHub, Linear oder Slack reicht ein API-Schlüssel nicht aus. Sie benötigen eine Anmeldung über einen Standardbenutzerablauf. Claude Code bietet integrierte OAuth-Unterstützung für diese Arten von MCP-Servern.

Shell-Befehle

Sie müssen keinen eigenen Login-Flow schreiben. Bevor Sie beginnen, können Sie überprüfen, für welche Server eine Authentifizierung erforderlich ist:

# List the MCP servers that need authentication
claude mcp list

Wenn Sie Server sehen, die nicht angemeldet sind, führen Sie einfach Folgendes aus:

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

Interaktive Befehle

Es gibt eine praktische Funktion. Wenn Sie Claude verwenden und ein Berechtigungsfehler auftritt, müssen Sie das Programm nicht beenden. Sie können direkt in der Chat-Sitzung autorisieren.

Beispiel:

>>> Du: Liste meine Todos auf.

>>> Claude: Ich brauche Zugang zu Linear.

>>> /mcp auth linearer server

Geben Sie einfach diesen Befehl ein. Claude wird den Login-Flow wieder aktivieren. Normalerweise wird der Browser geöffnet, damit Sie die Berechtigungen bestätigen können.

Ich bin einmal auf eine Situation gestoßen, in der das Linear-Token abgelaufen ist, als ich ein Problem überprüfte. Claude meldete auf halbem Weg unzureichende Berechtigungen.

Anstatt die CLI neu zu starten, habe ich einfach ausgeführt“/mcp auth„und es war geschafft. Unmittelbar danach kehrte ich zur Arbeit zurück.

Vorteile:

• Standard-OAuth-Ablauf.
• Tokens werden automatisch aktualisiert.
• Eine ziemlich reibungslose Erfahrung bei der Arbeit mit einem Benutzer.

Nachteile:

• Gelegentlich müssen Sie den Browser trotzdem öffnen und sich erneut anmelden. Vor allem, wenn Sie den Computer wechseln oder wenn die Anmeldesitzung endet.

Zusammenfassung

Die Wahl der Authentifizierungsmethode hängt von zwei Dingen ab:

• Wo Sie Ihre Anmeldeinformationen speichern.
• Und welches Problem du löst.

Es gibt keine Option „Das Beste für alle Orte“. Nur die, die zum Kontext passt. Ein kleiner, aber wichtiger Hinweis: Stellen Sie zunächst sicher, dass Ihre Node.js Umgebung stabil ist. Schließlich wurde festgestellt, dass der lokale Computer die falsche Node-Version verwendete. Ändern Sie es einfach auf“nvm verwenden„sollte normal funktionieren. Die Verwendung von nvm hilft, viele unerklärliche Fehler aufgrund von Umgebungsinkongruenzen zu vermeiden. Unterschätze das nicht.

Kurzanleitung: Hinzufügen von MCP-Servern in Claude Code

HTTP-Transport mit Auth-Header

# HTTP-Transport mit Auth-Header

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

# Studientransport (lokaler Prozess)

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

# Konfigurierte MCP-Server auflisten

claude mcp list

# Einen MCP-Server entfernen

claude mcp remove my-server

Es reicht aus, sich diese Befehle zu merken, um loszulegen. Im Rest geht es darum, die richtige Authentifizierungsmethode für die richtige Situation auszuwählen.

Häufig gestellte Fragen

Wie generiere ich das Claude Code MCP OAuth-Token?

Um ein Claude Code MCP OAuth-Token zu generieren, integrieren Sie in der Regel einen OAuth-Anbieter, der kurzfristige Zugriffstoken ausgibt. Diese hochsichere Methode verhindert, dass langfristige Anmeldeinformationen für Ihre Claude Code MCP-Verbindungen direkt preisgegeben werden. Die spezifischen Schritte hängen von der Konfiguration Ihres ausgewählten OAuth-Anbieters und seiner Integration mit Claude Code ab.

Kann Claude Code auf MCP-Server zugreifen?

Ja, Claude Code kann auf MCP-Server zugreifen und ermöglicht so die Interaktion mit externen Systemen wie Datenbanken und APIs. Diese Funktion macht Claude Code von einem Text-Responder zu einem aktiven Systemteilnehmer. Eine effektive Claude-Code-MCP-Authentifizierung ist für einen sicheren Betrieb unerlässlich, verhindert unbefugten Zugriff und gewährleistet die Datenintegrität in der gesamten US-Infrastruktur.

Wie authentifiziere ich figma MCP in Claude Code?

Um Figma MCP in Claude Code zu authentifizieren, müssen Sie eine sichere Claude MCP-Authentifizierungsmethode wählen. Dies beinhaltet in der Regel die Verwendung von API-Schlüsseln, OAuth- oder Bearer-Token, abhängig von der Integration von Figma und Ihren Sicherheitsrichtlinien. Konzentrieren Sie sich darauf, minimale Rechte zu gewähren und langfristige Schlüssel zu vermeiden, um eine sichere Systeminteraktion zu gewährleisten.