MCP-Authentifizierung in Claude Code – Leitfaden 2026

Was ist MCP?

MCP (Model Context Protocol) ist ein von Anthropic entwickelter offener Standard, der es Claude Code ermöglicht, auf strukturierte Weise mit externen Systemen zu kommunizieren.
Anstatt Tool-Logik in den Prompt zu packen, erstellt MCP eine klare Middleware-Schicht. Claude ruft das Tool in einem Standardformat auf. Der MCP server empfängt die Anfrage und leitet sie an das tatsächliche Dahinterliegende System weiter, wie etwa eine Datenbank, eine interne API, einen Cloud-Dienst oder ein Ticket-Management-System.

Sie können sich den MCP server wie eine Adapter-Schicht vorstellen. Auf der einen Seite befindet sich Claude Code. Auf der anderen Seite Ihre physische Infrastruktur. Er hilft beiden Seiten, einander zu verstehen, ohne dass bei jeder Integration alles von Grund auf neu geschrieben werden muss.

Ohne MCP hat Claude Code nur auf Text reagiert. Mit MCP beginnt es, mit dem realen System zu interagieren. Und ab diesem Zeitpunkt ist es nicht mehr nur "KI, die zum Spaß antwortet".

Warum die MCP-Authentifizierung wichtig ist

Da MCP immer beliebter wird, sehe ich viele Leute, die Claude Code verwenden, um sich direkt mit internen Systemen zu verbinden. Einige rufen nur API-Tests auf. Andere verbinden sich direkt mit Diensten, die auf AWS mit striktem IAM laufen.

Das Problem ist: Sobald Claude das Tool aufrufen kann, repräsentiert es eine Art Identität innerhalb Ihres Systems.

Wenn die Authentifizierungskonfiguration locker ist, zeigt sich das Risiko nicht sofort. Es ist schleichend. So wie damals, als ich eine CloudFront-Konfiguration debuggte. Es war nur eine scheinbar harmlose Forward-Header-Regel. Keine 500er-Fehler, keine Ausfallzeit. Aber in Wirklichkeit wurde die Zugriffsgrenze mehr als erwartet erweitert. Man muss die Logs sorgfältig prüfen, um das Problem zu finden.

Dasselbe gilt für MCP. Wenn Sie die falsche Authentifizierungsmethode wählen, könnten Sie unbeabsichtigt:

• Ihren langfristigen API key offenlegen
• Zugriffsschlüssel an mehrere verschiedene Benutzer verteilen
• Claude zu viele Berechtigungen erteilen, als notwendig sind.

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

Daher geht es bei der Wahl der richtigen Authentifizierungsmethode nicht nur darum, "die Verbindung zum Laufen zu bringen". Sie kann die Sicherheit und Konsistenz des gesamten dahinterstehenden Systems bestimmen.

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

Diese externen Tools sind weit davon entfernt, "harmlos" zu sein. Sie können Quellcode, Datensätze von Kunden, Produktionsdaten und interne Tickets enthalten. Aber wenn Claude sich über MCP verbindet, liest es nicht nur zum Spaß. Es agiert als verifizierte Identität tief in Ihrem System. Wenn die Authentifizierung schwach ist, könnten Sie angegriffen werden. Es ist kein komplexer Angriff erforderlich. Ein einziges durchgesickertes API key reicht aus, damit die Dinge sehr schnell schiefgehen.

Die Situation, auf die ich gestoßen bin, war ähnlich. Der Dienst stellt nur ein einfaches Token für die Entwicklungs- und Produktionsumgebungen bereit. Alles wäre in Ordnung, wenn diese Token-Informationen nicht beim Testen eines Repositorys durchgesickert wären. Daher müssen wir die Anmeldedaten sowohl für die Produktions- als auch für die Entwicklungsumgebung ändern, um das Aufkommen von Problemen zu vermeiden, sobald sie entdeckt werden. Das System selbst ist also nicht das Problem; das entscheidende Problem liegt darin, wie Sie Berechtigungen verwalten. Autorisierung ist nicht nur ein Zusatz; sie bestimmt, was Claude innerhalb seines zulässigen Bereichs tun kann, und verhindert Sicherheitsrisiken.

Womit befasst sich dieser Artikel?

Claude Code unterstützt mehrere verschiedene Authentifizierungsmethoden. Zum Beispiel:

• API key
• Bearer token
• OAuth
• AWS credential (Access Key oder Assume Role)

Auf den ersten Blick ist es verwirrend. Jede Methode existiert aus einem bestimmten Grund. Es gibt keinen "richtigen Weg für alle Fälle".

Die Wahl der falschen Methode kann führen zu:

• Offenlegung von Credentials
• Notwendigkeit einer Neukonfiguration auf halber Strecke
• Zeitverschwendung des Teams beim Reparieren von Workflows

Ich habe einmal einen MCP server konfiguriert, der hinter einem API Gateway auf AWS lief.

Anfangs nutzte ich langfristige Zugriffsschlüssel, um den Zugriff zu beschleunigen. Ich stellte jedoch fest, dass dies im Vergleich zum Teilen von Schlüsseln mit mehreren Testern für einen einfachen Zugriff nicht ideal war. Letztendlich bin ich auf rollenbasierte Assumptions umgestiegen, um Berechtigungen klarer zu definieren.

Dieser Artikel wird tief in jeden Punkt eintauchen und erklären, wann jede der verschiedenen Methoden zu verwenden ist. Das Ziel ist es, Ihnen zu helfen, von Anfang an die richtige Wahl zu treffen und zukünftige Änderungen zu vermeiden.

Installieren von Claude Code

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

macOS, Linux, WSL:

Windows PowerShell:

Nur MacOS

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

Definieren von Sicherheit in einer CLI-Umgebung

Beim Ausführen einer CLI auf einem lokalen Rechner denken viele Leute nur an HTTPS. Eigentlich liegt das größere Problem darin, wie Sie Ihre Credentials verwalten.

HTTPS schützt Daten nur während der Übertragung. Es hilft nicht, wenn das Token auf Ihrem Rechner offengelegt wird. In einer CLI-Umgebung sind die Hauptfragen:

• Wo speichern Sie den Schlüssel?
• Wie lange ist das Token gültig?
• Wer kann es verwenden?

Geringe Sicherheit liegt vor, wenn Sie einen langfristigen API key in einer Konfigurationsdatei im Klartext hinterlassen. Wenn diese Datei versehentlich im Repository committet wird, ist es vorbei. Dieser Schlüssel ist im Grunde außer Kontrolle. Und weil es sich um einen langfristigen Schlüssel handelt, müssen Sie ihn manuell rotieren.

Ich war einmal in einer ähnlichen Situation, als ich ein Umgebungsproblem mit ECS debuggte. Ich habe den Amazon ECS MCP Server mit einem Access Key und einem Secret Key verwendet. Danach habe ich diese Credentials vergessen. Ein paar Tage später bat ich Claude, einige Probleme in einer anderen Umgebung zu untersuchen, aber es verwendete immer noch die alten Credentials, sodass es schließlich viele Aktionen in der Produktionsumgebung ausführte.

Hohe Sicherheit ist anders. Sie verwenden kurzfristige Tokens. Oder die Referenzierung über Umgebungsvariablen. Oder die Verwendung von Authentifizierungsmechanismen auf Dienstebene wie IAM-Rollen. Wenn Sie beispielsweise AWS SSO verwenden, haben Tokens ein klares Ablaufdatum. Nach dem Ablauf müssen Sie sich erneut anmelden. Wenn der Rechner kompromittiert wird, hat der Angreifer nur ein sehr kurzes Zeitfenster, um etwas zu tun. Diese Methode ist nicht perfekt. Aber sie minimiert den Schaden, wenn etwas schiefgeht.

Nachfolgend finden Sie vier gängige Authentifizierungskonfigurationsmethoden für MCP servers in Claude Code. Jede Methode eignet sich für einen anderen Kontext.

1. Statische HTTP-Header (API Keys & Bearer Tokens)

Dies ist die einfachste Methode für den Einstieg. Dieser Weg funktioniert gut mit vielen Drittanbieterdiensten, die langfristige API keys oder Private Access Tokens (PATs) verwenden.

Befehlszeilenkonfiguration

Wenn Sie schnell einen MCP server mit einem Authentifizierungsheader hinzufügen möchten, verwenden Sie einfach „claude mcp add“ und übergeben Sie “--header”

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

Ich nutze sie oft, wenn ich eine API testen muss, bevor ich sie offiziell in das System integriere. Denken Sie nur an eine Sache: Fügt das eigentliche Token nicht in den Befehl ein und committet den Shell-Verlauf dann irgendwohin. Das passiert öfter, als man denkt.

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 liest „${ENV_VAR}“ und ersetzt es durch den tatsächlichen Wert, wenn die CLI startet.

Zum Beispiel:

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

Ich habe einmal gesehen, wie ein internes Repository versehentlich ein Token in die Konfiguration committet hat. Anstelle dachte ich, es sei ein privates Repository, also sei es in Ordnung. Dann wurde das Repository mit einem anderen Team zum Testen geteilt. Das Produktionstoken war ebenfalls enthalten. Die Verwendung von Umgebungsvariablen löst nicht alle Risiken. Aber zumindest verringert sie die Wahrscheinlichkeit einer Schlüsseloffenlegung beim versehentlichen Committen.

Vorteile:

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

Nachteile:

• Das Token ist immer noch ein langfristiger Typ.
• Bei einer Offenlegung müssen Sie es manuell rotieren.

2.1 AWS MCP Credentials

2.1 Access Key und Secret Key (für auf AWS gehostete MCP Servers)

Wenn sich Ihr MCP server auf AWS befindet, ist dies viel praktischer. Sie können die vorhandenen AWS-Anmeldedaten auf Ihrem Rechner verwenden. In der Regel wird dies über AWS configure oder AWS SSO konfiguriert. Claude erbt Variablen wie:

• AWS_ACCESS_KEY_ID
• AWS_SECRET_ACCESS_KEY
• AWS_SESSION_TOKEN
• AWS_PROFILE

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

Wie etwa das Konfigurieren eines MCP-Proxys zum Signieren von Anfragen mit Signature V4:

Oder einfacher, exportieren Sie Umgebungsvariablen vor dem Ausführen von Claude:

# Set AWS credentials before running Claude Code

# Start Claude Code — the MCP server will use these credentials claude

Claude muss die Schlüsseldetails 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. Damals dachte ich, es sei ein Richtlinienproblem. Aber dann stellte ich fest, dass das AWS SSO-Zertifikat auf meinem Rechner abgelaufen war. Das erneute Ausführen des Befehls „aws sso login“ hat alles behoben. Seitdem habe ich mir immer notiert, dass registrierte Dienste die Sitzung überprüfen müssen, bevor daran gearbeitet wird, anstatt die Schuld bei IAM zu suchen.

Vorteile:

• Tokens sind über STS meist kurzfristig.
• Können automatisch rotiert werden.
• Höhere Sicherheit als langfristige API keys.

Nachteile:

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

2.2. IAM Role Assumption (Least Privilege Access)

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

Zum Beispiel das Testen, wie ein Dienst mit schreibgeschütztem Zugriff funktioniert. Oder wenn der MCP server nur eine feste IAM Role akzeptiert. Er erlaubt einzelnen Benutzern nicht, ihn direkt aufzurufen.

Ich bin auf einen solchen Fall gestoßen. Eine interne API erlaubte nur Backend-Rollen den Zugriff. Einzelne Benutzer wurden blockiert. Um lokal zu testen, musste man diese spezifische Rolle annehmen.

Der Workflow ist ziemlich klar:

1. Sie fordern das Annehmen einer IAM Role an.
2. AWS STS prüft, ob Sie die Berechtigung zur Nutzung von sts:AssumeRole haben. Wenn gültig, gibt STS ein temporäres Credential zurück.
3. Der MCP proxy verwendet dieses temporäre Credential, um den Zieldienst aufzurufen. Der Dienst sieht nur die Rolle, nicht Ihren einzelnen 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 zeitaufwendig ist. Wenn die Trust policy auch nur um eine Zeile falsch ist, funktioniert das Annehmen nicht. Und das Debuggen von IAM ist nie eine unterhaltsame Aufgabe.

Konfigurationsbeispiel

Einrichten von IAM-Berechtigungen zum Annehmen von Rollen

Um eine Rolle anzunehmen, muss Ihr aktueller Benutzer über diese Berechtigung verfügen. Ohne die korrekte Trust policy stoppt sofort alles.

Meistens definiere ich der Einfachheit halber ein paar Variablen:

# Define variables

# Update the role's trust policy to allow your user to assume it

Dieser Abschnitt macht im Grunde nur eine Sache. Er teilt AWS mit, dass Ihr Benutzer diese Rolle annehmen darf.

Ich habe einmal fast einen ganzen Nachmittag verschwendet, nur weil mir der richtige ARN in der Trust policy fehlte. Die an die Rolle angehängte Richtlinie war korrekt. Aber die Trust policy erlaubte dem Benutzer das Annehmen nicht. Infolgedessen gab STS weiterhin einen AccessDenied-Fehler zurück. Ein weiterer Punkt, an den man sich erinnern sollte:

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

Vorteile:

• Wahrt das Prinzip der minimalen Berechtigungen (Least Privilege).
• Alles, was eine Rolle tun kann, liegt innerhalb ihrer Richtlinie.

Nachteile:

• Die Konfiguration ist etwas kompliziert.
• Schon ein kleiner Fehler und es funktioniert nicht.

3. Integrierte OAuth 2.0-Unterstützung

Für komplexe Drittanbieterdienste wie GitHub, Linear oder Slack reicht ein API key nicht aus. Sie erfordern die Anmeldung über einen Standard-Benutzer-Flow. Claude Code bietet integrierte OAuth-Unterstützung für diese Arten von MCP servers.

Shell-Befehle

Sie müssen Ihren eigenen Anmeldeflow nicht schreiben. Bevor Sie beginnen, können Sie überprüfen, welche Server eine Authentifizierung erfordern:

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

Interaktive Befehle

Es gibt eine praktische Funktion. Wenn Sie Claude verwenden und auf einen Berechtigungsfehler stoßen, müssen Sie nicht beenden. Sie können direkt innerhalb der Chat-Sitzung autorisieren. 

Beispiel: 

>>> Sie: Meine Todos auflisten.

>>> Claude: Ich benötige Zugriff auf Linear.

>>> /mcp auth linear-server

Geben Sie einfach diesen Befehl ein. Claude wird den Anmeldeflow reaktivieren. Normalerweise öffnet es den Browser, damit Sie die Berechtigungen bestätigen können.

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

 Anstatt die CLI neu zu starten, habe ich einfach „/mcp auth“ ausgeführt und es war erledigt. Ich bin direkt danach wieder an die Arbeit gegangen.

Vorteile:

• Standardmäßiger OAuth-Flow.
• Tokens werden automatisch aktualisiert.
• Ein ziemlich reibungsloses Erlebnis beim Arbeiten mit einem Benutzer.

Nachteile:

• Gelegentlich müssen Sie immer noch den Browser öffnen und sich erneut anmelden. Insbesondere beim Wechseln des Computers oder wenn die Anmeldesitzung endet.

Zusammenfassung

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

• Wo Sie Ihre Credentials speichern.
• Und welches Problem Sie lösen.

Es gibt keine Option "für alle Orte am besten". Nur diejenige, die zum Kontext passt. Ein kleiner, aber wichtiger Hinweis: Stellen Sie zuerst sicher, dass Ihre Node.js-Umgebung stabil ist. Schließlich stellte ich fest, dass der lokale Rechner die falsche Node-Version verwendete. Ein einfaches Ändern in „nvm use" sollte wie gewohnt funktionieren. Die Verwendung von nvm hilft, viele unerklärliche Fehler aufgrund von Umgebungsabweichungen zu vermeiden. Unterschätzen Sie das nicht. 

Kurzanleitung: Hinzufügen von MCP Servers in Claude Code

HTTP-Transport mit Auth-Header

# HTTP transport with auth header

# Stdio transport (local process)

# List configured MCP servers

# Remove an MCP server

Sich einfach an diese Befehle zu erinnern, reicht aus, um loszulegen. Der Rest dreht sich darum, die richtige Authentifizierungsmethode für die richtige Situation zu wählen.

Ein Gateway für jeden MCP server — OAuth, im Vault verwahrte Schlüssel und RBAC pro Tool, ohne Einrichtung pro Entwickler.

MCP Gateway ansehen →

Häufig gestellte Fragen (FAQ)

Wie generiert man einen Claude Code MCP OAuth Token?

Um ein Claude Code MCP OAuth Token zu generieren, integrieren Sie sich in der Regel mit einem OAuth-Anbieter, der kurzfristige Zugriffstokens ausstellt. Diese hochsichere Methode hilft, die direkte Offenlegung langfristiger Credentials für Ihre Claude Code MCP-Verbindungen zu verhindern. Die spezifischen Schritte hängen von der Einrichtung Ihres gewählten OAuth-Anbieters und seiner Integration mit Claude Code ab.

Kann Claude Code auf MCP-Server zugreifen?

Ja, Claude Code kann auf MCP servers zugreifen, was die Interaktion mit externen Systemen wie Datenbanken und APIs ermöglicht. Diese Funktionalität verwandelt Claude Code von einem Text-Antworter in einen aktiven Systemteilnehmer. Eine effektive Claude Code MCP-Authentifizierung ist für sichere Operationen unerlässlich, verhindert unbefugten Zugriff und gewährleistet die Datenintegrität über Ihre Infrastruktur hinweg.

Wie authentifiziert man 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 typischerweise die Verwendung von API keys, OAuth oder Bearer Tokens, abhängig von der Integration von Figma und Ihren Sicherheitsrichtlinien. Konzentrieren Sie sich darauf, minimale Berechtigungen zu gewähren und langfristige Schlüssel zu vermeiden, um eine sichere Systeminteraktion zu gewährleisten.