Ein KI-Assistent soll offene Supporttickets zusammenfassen. Dafür braucht er Zugriff auf das Ticketsystem. Doch darf er nur lesen? Auch Antworten verschicken? Oder sogar Tickets löschen?
Genau an dieser Stelle entscheidet sich, ob eine praktische KI-Anbindung kontrollierbar bleibt. Eine funktionierende Verbindung allein beantwortet diese Fragen noch nicht.
MCP-Authentifizierung und Autorisierung sorgen gemeinsam dafür, dass ein MCP-Server Anfragen prüfen und Zugriffe begrenzen kann. Bei geschützten HTTP-Verbindungen spielen OAuth und Access Tokens eine zentrale Rolle. Ob eine konkrete Aktion erlaubt ist, muss der Server zusätzlich anhand seiner Berechtigungsregeln entscheiden.
In diesem Artikel erfährst du, wie das Zusammenspiel funktioniert, warum ein Token kein Generalschlüssel sein sollte und wie du typische Zugriffsfehler systematisch eingrenzt.
Was bedeutet MCP-Authentifizierung überhaupt?
Das Model Context Protocol, kurz MCP, verbindet KI-Anwendungen mit Werkzeugen und Datenquellen. Die KI-Anwendung enthält einen MCP-Client; ein MCP-Server stellt beispielsweise eine Ticketsuche oder eine Dokumentenabfrage bereit. Die Grundlagen erklärt unser Artikel MCP einfach erklärt: Was ist das Model Context Protocol? (Zum Artikel)
Beim Zugriff sind zwei Begriffe zu unterscheiden:
| Begriff | Die entscheidende Frage | Beispiel |
|---|---|---|
| Authentifizierung | Wer meldet sich an? | Eine Mitarbeiterin weist ihre Identität beim Unternehmenslogin nach. |
| Autorisierung | Was ist erlaubt? | Der Client darf für sie Tickets aus dem Supportbereich lesen. |
OAuth ist vor allem ein Verfahren zur delegierten Autorisierung. Es ermöglicht einer Anwendung begrenzten Zugriff, ohne ihr das Benutzerpasswort auszuhändigen. OpenID Connect ergänzt OAuth um eine standardisierte Identitätsschicht für die Anmeldung. Ein OIDC-ID-Token und ein API-Access-Token haben deshalb unterschiedliche Aufgaben: Das ID-Token ist kein allgemeiner Ersatz für das Access Token am MCP-Server.
Quelle: OpenID Connect Core
Für den Alltag hilft ein Bürovergleich: Die Anmeldung bestätigt deine Identität. Die Zugangskarte öffnet bestimmte Türen. Hinter der Tür können weitere Regeln gelten, etwa für einzelne Aktenschränke.
Lokales MCP und HTTP: Warum die Verbindung wichtig ist
Die MCP-Autorisierungsspezifikation beschreibt HTTP-basierte Verbindungen. Sie lässt Autorisierung grundsätzlich optional; sobald vertrauliche Informationen oder administrative Funktionen erreichbar sind, braucht die Anwendung jedoch ein geeignetes Zugriffskonzept.
Bei STDIO startet ein Client einen lokalen MCP-Prozess und kommuniziert über dessen Standardein- und -ausgabe. Für diese Verbindung sieht MCP nicht denselben HTTP-OAuth-Ablauf vor. Zugangsdaten können aus der Prozessumgebung kommen. Bei einer HTTP-Verbindung greift der Client über einen Endpunkt auf den Server zu; hier ist der standardisierte OAuth-Ablauf relevant. Entscheidend ist der Transport, nicht allein der Standort des Rechners.
Quelle: MCP Authorization
Ein lokaler Prozess kann seinerseits OAuth für einen externen Dienst benötigen. Außerdem bedeutet „lokal" nicht automatisch „sicher": Welche Dateien kann der Prozess lesen? Welche Betriebssystemrechte besitzt er? Welche Zugangsdaten werden ihm mitgegeben?
Praxisempfehlung: Starte einen lokalen MCP-Server mit genau den Dateizugriffen und Credentials, die seine Aufgabe erfordert. Ein Werkzeug zur Dokumentensuche braucht normalerweise weder deinen gesamten privaten Ordner noch administrative Rechte.
Wenn du selbst eine Anbindung bauen möchtest, findest du einen Einstieg unter Eigenen MCP Server erstellen: Architektur und Praxisbeispiel (Zum Artikel)
OAuth, Access Token, Refresh Token: Was ist was?
Diese Begriffe gehören zusammen, sind aber nicht austauschbar:
| Begriff | Aufgabe | Worauf du achten solltest |
|---|---|---|
| OAuth | Regelt die Vergabe begrenzter Zugriffsrechte | Unterstützte Abläufe und Client-Kompatibilität prüfen |
| Access Token | Wird für den Zugriff auf eine geschützte Ressource verwendet | Gültigkeit, Empfänger und Berechtigungen prüfen |
| Bearer Token | Token, dessen Besitz grundsätzlich zur Verwendung ausreicht | Vor Offenlegung schützen |
| Refresh Token | Ermöglicht beim Autorisierungsserver neue Access Tokens | Besonders geschützt speichern; nicht an den MCP-Endpunkt senden |
| Scope | Bezeichnet einen freigegebenen Berechtigungsumfang | Möglichst klein und verständlich halten |
| API-Key | Anbieterabhängiger Zugangsschlüssel | Ist nicht automatisch eine vollständige OAuth-Integration |
| Client-ID | Kennzeichnet eine OAuth-Anwendung | Ist grundsätzlich kein geheimes Passwort |
Ein Access Token wird beim üblichen Bearer-Verfahren im HTTP-Header übertragen:
Authorization: Bearer <ACCESS_TOKEN>Das ist eine schematische Darstellung mit Platzhalter. Weil ein gestohlenes Bearer Token missbraucht werden kann, sind HTTPS, sichere Speicherung und sparsame Protokollierung entscheidend. Tokens gehören nicht in URLs, Screenshots oder Supportbeiträge.
Quelle: RFC 6750
Refresh Tokens sind keine Garantie für unbegrenzten Zugriff. Ihre Ausgabe und Gültigkeit hängen vom Autorisierungsserver ab. Rotation kann einen verwendeten Refresh Token durch einen neuen ersetzen und hilft, Wiederverwendung gestohlener Tokens zu erkennen.
Quelle: OAuth Security Best Current Practice
So läuft ein OAuth-Zugriff auf einen MCP-Server ab
Stell dir vor, eine Mitarbeiterin verbindet ihren KI-Assistenten mit einem geschützten Dokumentenserver. Vereinfacht passiert Folgendes:
- Zugriff starten: Der MCP-Client versucht, den geschützten Endpunkt zu erreichen.
- Anmeldeinformationen finden: Eine 401-Antwort kann auf Metadaten verweisen, über die der Client den zuständigen Autorisierungsserver findet.
- Client zuordnen: Die Anwendung verwendet eine passende Client-Registrierung.
- Anmelden und Rechte freigeben: Die Mitarbeiterin meldet sich im Browser beim vorgesehenen Anbieter an und bestätigt die angefragten Rechte, soweit eine Zustimmung erforderlich ist.
- Code gegen Token tauschen: Der Client erhält einen kurzlebigen Autorisierungscode und tauscht ihn unter Verwendung von PKCE gegen ein Access Token.
- Geschützt zugreifen: Der Client sendet das Token an den MCP-Server. Dieser prüft den Zugriff, bevor er Daten herausgibt.
Die Anmeldung erfolgt beim Anmeldedienst. Das Passwort gehört nicht als Nachricht in den KI-Chat.
Quelle: MCP Authorization Tutorial
Was ist Discovery?
Discovery bedeutet, dass der Client die benötigten Endpunkte über standardisierte Metadaten ermittelt. Der MCP-Server kann dafür ein Dokument mit Informationen über seine geschützte Ressource bereitstellen.
Ein vereinfachtes Beispiel für eine selbst entworfene Ticketanbindung:
HTTP/1.1 401 Unauthorized
WWW-Authenticate: Bearer resource_metadata="https://mcp.example.com/.well-known/oauth-protected-resource", scope="tickets:read"Das referenzierte Dokument könnte so aussehen:
{
"resource": "https://mcp.example.com/mcp",
"authorization_servers": ["https://login.example.com"],
"scopes_supported": ["tickets:read"]
}Die Domains sind Beispiele. Auch tickets:read ist ein frei gewählter Beispiel-Scope und kein universeller MCP-Standard. Metadaten beschreiben, wo und wie eine Autorisierung möglich ist; sie erteilen selbst keine Berechtigung.
Quelle: RFC 9728
Warum braucht OAuth PKCE?
PKCE bindet den Autorisierungscode an den Client, der den Anmeldevorgang begonnen hat. Der Client erzeugt einen geheimen Zufallswert und sendet zunächst einen daraus abgeleiteten Prüfwert. Beim späteren Tokenabruf muss er den ursprünglichen Wert vorlegen.
Ein abgefangener Code allein soll dadurch nicht reichen, um ein Token zu bekommen. PKCE schützt diesen Austausch; ein anschließend gestohlenes Access Token wird dadurch nicht automatisch unbrauchbar.
Quelle: RFC 7636
Versionshinweis: Die recherchierte MCP-Spezifikation 2026-07-28 führt Client ID Metadata Documents, Vorregistrierung und Dynamic Client Registration auf. DCR ist dort als veraltet und zur Rückwärtskompatibilität beibehalten gekennzeichnet. Ältere Tutorials können andere Schwerpunkte setzen. Prüfe die tatsächlich unterstützte MCP-Version von Client und Server.
Quelle: MCP Authorization
Warum ein gültiges Token nicht ausreicht
Ein Token kann technisch echt sein und trotzdem für die angefragte Ressource ungeeignet sein. Zwei Prüfbereiche sind besonders wichtig.
1. Ist das Token für diesen Server bestimmt?
Der vorgesehene Empfänger wird häufig als Audience bezeichnet. Über einen resource-Parameter kann der Client bei der Autorisierung angeben, für welche Ressource er Zugriff beantragt. Ein Token für das Ticketsystem sollte nicht einfach auch am Personalportal funktionieren.
Resource Indicators helfen, diese Grenzen technisch abzubilden. Die Gegenseite muss die Empfängerbindung tatsächlich prüfen. Nur weil ein Token von einem bekannten Anmeldedienst stammt, ist es nicht für jeden Dienst zulässig.
Quelle: RFC 8707
2. Sind Token und Berechtigungen korrekt geprüft?
Bei einem JWT reicht es nicht, den Inhalt zu decodieren. Die Anwendung muss unter anderem die kryptografische Prüfung, erlaubte Algorithmen, den erwarteten Aussteller und die Empfängerbindung berücksichtigen. Ein lesbares Token ist noch kein vertrauenswürdiges Token.
Quelle: RFC 8725
Nicht jedes Access Token ist ein JWT. Bei einem undurchsichtigen Token kann ein Resource Server eine geschützte Introspection-Schnittstelle des Autorisierungsservers nutzen. Deren Antwort kann beispielsweise Auskunft über den aktiven Status und die Scopes geben. Auch diese Ergebnisse müssen in die lokale Zugriffsentscheidung einfließen.
Quelle: RFC 7662
Für Implementierungen: Verwende etablierte OAuth-Bibliotheken und geeignete SDK-Funktionen. Selbst geschriebene Tokenprüfung wird schnell unvollständig.
Praxisbeispiel: Tickets zusammenfassen, ohne Änderungen zu erlauben
Ein kleines Unternehmen möchte jeden Morgen eine Übersicht offener Supportfälle erhalten. Für diesen Artikel entwerfen wir dafür folgende Berechtigungsmatrix:
| Aktion | Erlaubt? | Technische Begrenzung im Beispiel |
|---|---|---|
| Offene Tickets suchen | Ja | Lesender Scope und erlaubte Supportwarteschlange |
| Ticketdetails laden | Ja | Prüfung des Mandanten und der Ticketberechtigung |
| Kommentare schreiben | Nein | Schreibender Scope fehlt; Server verweigert die Aktion |
| Tickets löschen | Nein | Keine Löschberechtigung und kein entsprechendes Agentenwerkzeug |
| Zugangsdaten anzeigen | Nein | Secrets sind kein Bestandteil der Tool-Ausgabe |
Der Beispiel-Scope tickets:read allein bildet die ganze Zugriffskontrolle noch nicht ab. Der Server muss auch prüfen, welche Tickets die aufrufende Identität sehen darf. Sonst könnte eine geänderte Ticket-ID Daten eines anderen Teams oder Mandanten erschließen.
Meine Empfehlung für den Abnahmetest: Prüfe neben einer erlaubten Abfrage bewusst drei Ablehnungen – ein fremdes Ticket, einen Schreibversuch und einen Zugriff mit abgelaufenem Token. Erst wenn diese Grenzen funktionieren, ist die Lesefunktion sinnvoll abgesichert.
Mehr zur Gestaltung solcher Rollen findest du unter Role-Based Access Control für AI Agents (Zum Artikel)
Passendes Produkt in meinem Shop
MCP Server Praxisleitfaden 2026
Zeigt Installation und sicheren Betrieb lokaler und entfernter MCP-Server – inklusive Least Privilege, API-Tokens, OAuth/OIDC und Logging. Auch für Docker-, Kubernetes- und Proxmox-Umgebungen relevant, wenn KI-Agenten kontrollierten Zugriff auf Infrastruktur erhalten sollen.
Der gefährliche Fehler: Tokens einfach weiterreichen
Ein MCP-Server kann als Vermittler zu weiteren APIs arbeiten. Dabei entsteht leicht die Idee, das vom Client empfangene Token unverändert an die nachgelagerte API weiterzugeben.
Dieses Token Passthrough ist im MCP-Autorisierungsmodell ausdrücklich untersagt. Es vermischt Vertrauensgrenzen und kann dazu führen, dass Tokens an Stellen verwendet werden, für die sie nicht ausgestellt wurden. Auch die Zuordnung von Aktionen und Sicherheitsprüfungen wird dadurch unzuverlässig.
Quelle: MCP Security Best Practices
Die saubere Trennung sieht so aus:
| Verbindung | Vorgesehener Nachweis |
|---|---|
| MCP-Client zum MCP-Server | Access Token für den MCP-Server |
| MCP-Server zur externen API | Separater, für diese API ausgestellter Zugang |
Der zweite Zugang muss zum berechtigten Benutzer oder zur vorgesehenen technischen Identität passen. Ein pauschales Administratorkonto würde die zuvor sorgfältig begrenzten Benutzerrechte sonst wieder aushebeln.
Sieben Regeln für kontrollierte MCP-Zugriffe
Die folgenden Punkte sind eine praktische Betriebscheckliste, keine vollständige Konformitätsprüfung.
- Rechte nach Aufgabe zuschneiden. Lege fest, welche Daten und Aktionen eine Anbindung benötigt. Beginne für Analyseaufgaben mit Lesen.
- Credentials vom Modellkontext fernhalten. Speichere Tokens im dafür vorgesehenen Credential Store. Sie gehören nicht in Prompts, Tool-Beschreibungen oder normale Ergebnisdaten.
- Tokenlaufzeiten und Rotation planen. Die MCP-Sicherheitshinweise empfehlen kurzlebige Access Tokens und verlangen bei öffentlichen Clients die Rotation von Refresh Tokens.
- HTTPS und Redirects korrekt konfigurieren. Öffentliche Anmeldeendpunkte brauchen HTTPS. Registriere Rücksprungadressen präzise und verwende die Sicherheitsprüfungen der OAuth-Bibliothek.
- Zugriffsentzug testen. Prüfe, was nach dem Entfernen einer Freigabe tatsächlich passiert. Ein lokal validiertes Access Token kann ohne zusätzliche Gegenmaßnahmen bis zu seinem Ablauf wirksam bleiben.
- Aussagekräftig und sparsam protokollieren. Erfasse Identität, Aktion, Ziel, Ergebnis und Zeitpunkt. Vollständige Tokens gehören nicht ins Audit-Log.
- Riskante Aktionen gesondert kontrollieren. Definiere für Versand, Löschung oder Produktionsänderungen geeignete Freigaben und serverseitige Grenzen.
Die technischen Grundlagen für Tokenspeicherung, Refresh-Rotation und Redirect-Schutz stehen in den MCP-Sicherheitshinweisen. Für Widerruf und dessen Umsetzung ist RFC 7009 relevant. Hinweise zur Ablage von Zugangsdaten findest du außerdem unter Secrets und API-Keys bei KI-Agenten schützen (Zum Artikel)
OAuth bewertet nicht, ob eine von der KI vorgeschlagene Aktion fachlich sinnvoll ist. Eine manipulierte Dokumentenanweisung kann weiterhin versuchen, einen Agenten zu einer unerwünschten Handlung zu bewegen. Deshalb sollten Berechtigungsgrenzen auch dann halten, wenn sich der Agent falsch verhält.
401 oder 403? So grenzt du Authentifizierungsfehler ein
Eine erneute Anmeldung löst nicht jeden Zugriffsfehler. Diese Reihenfolge hilft bei der Diagnose:
| Beobachtung | Mögliche Ursache | Sinnvoller Prüfschritt |
|---|---|---|
| 401 Unauthorized | Token fehlt, ist abgelaufen oder ungültig | Header, Ablaufzeit und Tokenprüfung untersuchen |
| 403 Forbidden | Rechte oder Scopes reichen nicht aus | Erforderliche Berechtigung und Objektzugriff prüfen |
| Browserlogin gelingt, MCP-Zugriff scheitert | Token gilt für eine andere Ressource | Resource/Audience und Aussteller vergleichen |
| Wiederholte Anmeldung | Refresh scheitert oder Tokens werden nicht gespeichert | Client-Speicher und Refresh-Konfiguration prüfen |
| Redirect-Fehler | Callback passt nicht zur registrierten Adresse | Schema, Host, Port und Pfad vergleichen |
| Funktioniert nur ohne Reverse Proxy | Header, Metadaten oder externe URLs kommen verändert an | Weiterleitung und öffentlich sichtbare Endpunkte prüfen |
Die Bedeutung von invalid_token und insufficient_scope beschreibt RFC 6750. Die weiteren Zeilen sind Diagnosehypothesen, die du anhand deiner Installation überprüfen musst.
Admin-Tipp: Ein vorgeschaltetes Browserlogin ist allein kein Nachweis für eine MCP-kompatible OAuth-Integration. Prüfe auch, ob der verwendete Client Discovery, Tokenabruf und Berechtigungsanforderungen der Installation unterstützt. Schalte die Tokenprüfung nicht ab, um eine 401-Antwort zu beseitigen.
Wie funktionieren MCP-Zugriffe ohne angemeldeten Menschen?
Ein nächtlicher Monitoring-Job braucht häufig eine technische Identität. Dafür gibt es eine optionale MCP-Erweiterung für OAuth Client Credentials. Der Client handelt dabei im eigenen Namen innerhalb zuvor vergebener Rechte; ein interaktiver Benutzerlogin ist nicht der Kern dieses Ablaufs.
Das ist keine automatisch verfügbare Funktion jeder MCP-Anbindung. Die beteiligten Komponenten müssen die Erweiterung unterstützen. Trenne außerdem fachlich zwischen „Automatisierung handelt für einen Benutzer" und „Dienst handelt mit eigenen Rechten".
Quelle: MCP OAuth Client Credentials
Für unseren Ticketbericht wäre ein eigenes lesendes Dienstkonto eine mögliche Architekturentscheidung. Ob diese passend ist, hängt davon ab, ob der Bericht individuelle Benutzerrechte berücksichtigen muss oder eine klar definierte Teamansicht auswertet.
Häufige Fragen zur MCP-Authentifizierung
Muss jeder MCP-Server OAuth verwenden?
Nein. Transport, Daten und Einsatzszenario sind entscheidend. Das standardisierte MCP-Autorisierungsverfahren richtet sich an HTTP-Verbindungen. Für vertrauliche Daten brauchst du unabhängig davon wirksame Zugriffskontrollen.
Ist ein API-Key dasselbe wie OAuth?
Nein. Ein API-Key ist ein Zugangsschlüssel. OAuth beschreibt einen Ablauf zur Vergabe begrenzter Zugriffsrechte. Dass eine Anwendung einen Schlüssel akzeptiert, sagt noch nichts über ihre MCP-OAuth-Kompatibilität aus.
Verhindert eine Anmeldung mit MFA jeden Tokenmissbrauch?
Nein. MFA stärkt den Anmeldevorgang. Ein danach gestohlenes Bearer Token kann weiterhin nutzbar sein. Schütze daher auch Speicherung, Übertragung und Laufzeit der Tokens.
Darf ich ein Token zur Fehlersuche in einen Chat kopieren?
Verwende dafür keine echten Tokens. Teile stattdessen Fehlermeldungen und bereinigte Konfigurationsangaben. Auch decodierte Tokeninhalte können persönliche oder interne Informationen enthalten.
Wie beginne ich mit einer eigenen Anbindung?
Definiere zuerst eine kleine, lesende Aufgabe und ihre Datenzugriffe. Wähle anschließend einen kompatiblen Authentifizierungsweg und prüfe erlaubte sowie verweigerte Aktionen. So lässt sich ein Fehler leichter eingrenzen als bei einer Anbindung mit Vollzugriff.
Dein nächster Schritt: Eine Verbindung gezielt prüfen
Nimm eine MCP-Anbindung, die du bereits nutzt oder einrichten möchtest. Notiere, welche Identität sie verwendet, welche Daten sie erreichen darf und wie du den Zugriff wieder entziehst. Teste anschließend eine Aktion, die ausdrücklich verboten sein soll.
Damit wird aus „Die Verbindung funktioniert" eine überprüfbare Aussage darüber, was sie tatsächlich darf.
Du möchtest MCP-Sicherheit insgesamt vertiefen? MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel) fasst die wichtigsten Schutzmaßnahmen zusammen. Weitere Anleitungen zu MCP, KI-Agenten und Systemadministration gibt es im KI-Buster-Blog (Zum Artikel)
Weiterführende Themen und Quellen
MCP einfach erklärt: Was ist das Model Context Protocol? (Zum Artikel)
Eigenen MCP Server erstellen: Architektur und Praxisbeispiel (Zum Artikel)
Role-Based Access Control für AI Agents (Zum Artikel)
Secrets und API-Keys bei KI-Agenten schützen (Zum Artikel)
MCP Server sicher betreiben: Rechte, Tools und Risiken erklärt (Zum Artikel)
Offizielle Dokumentation, zuletzt geprüft am 30. September 2026: MCP: Authorization-Spezifikation, MCP: Authorization-Tutorial, MCP: Security Best Practices, MCP: OAuth Client Credentials Extension, OpenID Connect Core 1.0, RFC 6750 – Bearer Token Usage, RFC 7636 – PKCE, RFC 7662 – Token Introspection, RFC 7009 – Token Revocation, RFC 8707 – Resource Indicators, RFC 8725 – JWT Best Current Practices, RFC 9728 – Protected Resource Metadata, RFC 9700 – OAuth 2.0 Security Best Current Practice.
Faktenprüfung: 30. September 2026. Die technischen Angaben wurden direkt anhand der MCP-Autorisierungsspezifikation und der zugehörigen Security-Best-Practices-Dokumentation in der Version 2026-07-28 sowie den zitierten IETF-RFCs geprüft. OAuth 2.1 ist zu diesem Zeitpunkt weiterhin ein IETF-Entwurf und keine verabschiedete RFC; die MCP-Spezifikation verweist entsprechend auf den aktuellen Draft. Das Praxisbeispiel ist ein entworfenes Szenario zur Veranschaulichung, kein durchgeführter Produktivtest.