Das ist die Sache mit der MCP-Autorisierung, die niemand klar erklärt: Sie ist keine benutzerdefinierte Sicherheitsschicht, die Anthropic erfunden hat. Sie ist OAuth 2.1, angewendet auf einen spezifischen neuen Kontext, mit einer Reihe von Rollenzuweisungen, die die Spezifikation präzise definiert. Die Verwirrung betrifft nicht die Technologie. Sie betrifft die Frage, welcher Teil welche Aufgabe übernimmt und wo die Grenze zwischen der Komponente liegt, die Tokens ausstellt, und der Komponente, die sie durchsetzt.
Ich habe erlebt, dass diese Verwirrung zu Produktionsausfällen führt, und das Muster ist mittlerweile fast vorhersehbar. Ein Team verbindet einen MCP-Server, bestätigt, dass der Client eine Verbindung herstellen kann, und nennt ihn daraufhin „autorisiert“. Drei Monate später fragt jemand, warum ein Agent ein Schreib-Tool aufrufen kann, das er nie verwenden sollte. Die Antwort lautet in der Regel, dass das Token korrekt ausgestellt wurde, aber niemand die Scope-Durchsetzung auf Serverseite implementiert hat. Zwei unterschiedliche Probleme. Eine nicht umgesetzte Lösung.
Die MCP-Autorisierungsspezifikation ist konkret. Sie umfasst klar abgegrenzte Rollen, spezifische RFC-Abhängigkeiten und nicht verhandelbare Muster dafür, wie Tokens übertragen werden. Diese Muster zu verstehen, unterscheidet ein Setup, das funktioniert, von einem, das nur so aussieht, als würde es funktionieren – bis es das nicht mehr tut.
Der Teil, den Teams zu spät lernen
- Die MCP-Autorisierung ist OAuth 2.1 für KI-Agent-Kontexte, kein neues Protokoll, das für MCP erfunden wurde.
- Der Autorisierungsserver und der MCP-Server haben getrennte, sich nicht überschneidende Aufgaben – ihre Vermischung ist der Ausgangspunkt der meisten Produktionsprobleme.
- Authentifizierung bestätigt die Identität; Autorisierung setzt durch, was diese Identität tun darf. Die Spezifikation behandelt beides, jedoch über getrennte Mechanismen, die jeweils implementiert werden müssen.
- Die Integration von Enterprise-SSO erfordert bewusste Architekturarbeit, die deutlich über das hinausgeht, was die Basisspezifikation bietet.
- „Auf Protokollebene optional“ bedeutet nicht optional im Produktivbetrieb.
Was MCP-Autorisierung tatsächlich ist – und was die Spezifikation abdeckt
MCP-Autorisierung ist der Mechanismus, über den HTTP-basierte MCP-Clients OAuth-2.1-Zugriffstokens von einem dedizierten Autorisierungsserver erhalten und diese Tokens MCP-Servern präsentieren, die als Ressourcenserver fungieren. Dieser Satz enthält drei bewegliche Teile, und jeder davon ist wichtig.
Der MCP-Client ist der Verbraucher: ein KI-Agent, ein IDE-Copilot oder ein Automatisierungs-Workflow, der Anfragen stellt. Der Autorisierungsserver ist ein separater Dienst, der den Client authentifiziert, die Einwilligung der Nutzenden einholt und Tokens ausstellt. Der MCP-Server erhält diese Tokens bei jeder Anfrage und validiert sie, bevor ein Tool ausgeführt werden darf. Im OAuth-2.1-Modell ist er der Ressourcenserver.
Was die Autorisierung in MCP abdeckt: Die Model-Context-Protocol-Spezifikation definiert exakt, wie dieser Token-Austausch erfolgt, welche Flows erforderlich sind und wie Clients überhaupt den Autorisierungsserver finden. Was sie nicht abdeckt: Was innerhalb Ihrer angebundenen APIs geschieht, nachdem das Token die Validierung bestanden hat. Diese Lücke ist wichtig, und darauf komme ich zurück.
Der Punkt, den die meisten Lesenden übersehen: Die Spezifikation kennzeichnet Autorisierung auf Protokollebene als optional, doch diese Kennzeichnung bezieht sich auf die minimal notwendige Konnektivität zwischen einem MCP-Client und einem MCP-Server in einem lokalen, vertrauenswürdigen Kontext. Für jeden HTTP-basierten MCP-Server, der nicht vertrauenswürdigen Clients zugänglich ist, sind die eigenen Empfehlungen der Spezifikation faktisch nicht optional. Die Optionalität ist eine Kennzeichnung auf Protokollebene, keine Entscheidung über Produktionssicherheit. Teams, die „optional“ lesen und die Implementierung überspringen, lernen diese Unterscheidung später von ihrem Security-Team kennen – unter weniger günstigen Bedingungen.
Warum das MCP-Autorisierungsmodell auf OAuth 2.1 statt auf einem neuen Protokoll aufbaut
Die bewusste Entscheidung, auf OAuth 2.1 aufzubauen, statt einen benutzerdefinierten Mechanismus zu erfinden, sollten Sie verstehen, bevor Sie eine MCP-Implementierung bewerten. Die MCP-Spezifikation musste Identität und Einwilligung nicht von Grund auf neu lösen. Für diese Probleme gibt es bereits Lösungen, und hinter diesen Lösungen steht bereits Infrastruktur.
Das ist eine Architekturentscheidung mit echten praktischen Auswirkungen. Wenn Ihr Team bereits OAuth-2.1-Infrastruktur betreibt, arbeiten Sie mit einer bekannten Sicherheitsoberfläche. Ihr Security-Team weiß, was geprüft werden muss. Ihr IdP weiß, womit er integriert werden muss. Sie führen keine vollständig neue Angriffsfläche in Ihre Produktionsumgebung ein. Das ist eine reale Risikoreduzierung, kein Marketingargument.
Die technische Analyse der MCP-Autorisierungsspezifikation von Aembit dokumentiert dies ausdrücklich: Die Spezifikation standardisiert den Client-Zugriff auf geschützte Ressourcen mit OAuth 2.1 und PKCE und führt Protected Resource Metadata ein, um die Zugriffskontrolle von MCP-Servern zu entkoppeln und an bestehende Identitätsinfrastruktur anzubinden. Die praktische Bedeutung dieser letzten Formulierung – „an bestehende Identitätsinfrastruktur anbinden“ – besteht darin, dass Teams mit bestehender OAuth-Autorisierung MCP in ihren vorhandenen Identity-Stack integrieren können, statt einen parallelen Stack aufzubauen.
Die Entscheidung, bestehende Autorisierungsmuster zu nutzen, ist für Architektinnen und Architekten relevant, die Risiken unter Zeitdruck bewerten. Sie prüfen die Implementierung, nicht das Protokoll. Fehler in Ihrer MCP-Autorisierungsimplementierung sind OAuth-2.1-Fehler, für die es bekannte Behebungswege, dokumentierte CVEs und eine Security-Community gibt, die sie findet. Ein benutzerdefiniertes Protokoll bietet nichts von dieser Historie.
OAuth-Autorisierung im MCP-Kontext bedeutet außerdem, dass der Authorization-Code-Flow das primäre Muster ist, wobei PKCE für öffentliche Clients erforderlich ist. Warum gerade diese Kombination sinnvoll ist, wird im nächsten Abschnitt deutlich.
Warum OAuth 2.1 und PKCE für KI-Agent-Clients die richtige Wahl sind
PKCE (Proof Key for Code Exchange) löst ein konkretes Problem: Wie schützen Sie einen OAuth-2.1-Autorisierungscode-Austausch, wenn der Client kein Geheimnis sicher speichern kann? Eine native Mobile-App kann ein Client-Secret nicht sicher speichern. Eine Browser-Erweiterung ebenfalls nicht. Und auch ein KI-Agent oder IDE-Copilot, der als öffentlicher Client läuft, kann das nicht.
Genau das ist das MCP-Host-Szenario. Wenn ein KI-Agent im Namen einer Person handelt, agiert er als öffentlicher Client. Ein Client-Secret in einem Agent-Prozess zu speichern, der in von Nutzenden kontrollierten Umgebungen läuft, ist keine wirksame Sicherheitskontrolle. Das Abfangen von Autorisierungscodes ist für diese Clients ein realer Angriffsweg, wenn der Austausch nicht geschützt ist.
PKCE schließt diese Lücke. Der Client erstellt vor der Autorisierungsanfrage einen Code Verifier, sendet einen Hash davon – die Code Challenge – mit der Anfrage und beweist anschließend beim Austausch des Autorisierungscodes gegen ein Token, dass er den ursprünglichen Verifier besitzt. Ein abgefangener Code ist ohne den Verifier nutzlos. MCP-Clients und MCP-Server, die in Public-Client-Szenarien arbeiten, erhalten einen wirksamen Schutz des Autorisierungscodes, ohne ein Geheimnis zu benötigen, das tatsächlich nicht geheim gehalten werden kann. Deshalb verlangt die Spezifikation PKCE – nicht als Best-Practice-Empfehlung, sondern als strukturelle Anforderung für diese Client-Klasse.
Die RFC-Abhängigkeiten, die die meisten Teams vor der Implementierung übersehen
Die MCP-Autorisierungsspezifikation steht nicht für sich allein. Sie hängt von einer Reihe von RFCs ab, die die meisten Teams vor dem Aufbau nicht vollständig erfassen. Wenn einer davon in Ihren MCP-Implementierungen fehlt, entsteht ein Setup, das teilweise konform ist und in bestimmten Sonderfällen vollständig versagt.
Die Checkliste, die konforme Implementierungen von fehlerhaften unterscheidet, basierend auf den Anforderungen der Spezifikation und Christian Postas Praxisanalyse:
- OAuth 2.1 mit PKCE – die zentrale Flow-Anforderung für öffentliche Clients; für HTTP-basierte Deployments nicht optional
- RFC 8414 – Authorization Server Metadata – ermöglicht Clients, Endpunkte von Autorisierungsservern automatisch über eine Well-Known-URL zu entdecken; ohne dies benötigen Clients fest kodierte Konfigurationen
- RFC 9728 – Protected Resource Metadata für Autorisierung – ermöglicht dem MCP-Server, Clients, die einen 401 erhalten, den Standort seines Autorisierungsservers mitzuteilen; so erfahren Clients überhaupt, wo sie Tokens beziehen können
- RFC 7591 – Dynamic Client Registration – ermöglicht Clients die programmatische Registrierung beim Autorisierungsserver; besonders wichtig für Tools und Agents, die nicht manuell vorregistriert werden können
- RFC 8707 – Resource Indicators – ermöglicht es, Tokens auf bestimmte Ressourcenserver zu beschränken und reduziert damit das Risiko, dass ein für einen MCP-Server ausgestelltes Token gegen einen anderen wiederverwendet wird
Teams, die OAuth 2.1 implementieren, aber RFC 9728 überspringen, erhalten Clients, die den Autorisierungsserver ohne manuelle Konfiguration nicht entdecken können. Teams, die RFC 7591 überspringen, haben eine Lücke bei der dynamischen Client-Registrierung, die relevant wird, sobald Sie Agents programmgesteuert in großem Umfang onboarden müssen. Die Metadaten zur Entdeckung von Autorisierungsservern in RFC 8414 machen den gesamten Handshake automatisierbar. Wenn sie fehlen, haben Sie etwas gebaut, das in Ihrer Testumgebung funktioniert und scheitert, sobald jemand einen neuen Client-Typ verbinden möchte.
So funktioniert der MCP-Autorisierungsflow: Rollen, Tokens und Verantwortungsgrenzen
Der Autorisierungsflow in MCP folgt einer bestimmten Reihenfolge, und die Rollenzuweisung in jedem Schritt ist der Teil, bei dem die meisten Teams durcheinanderkommen. Sehen wir ihn uns mit klaren Grenzen an, denn genau an diesen Grenzen liegen die meisten Implementierungsfehler.
Ein Client versucht, einen geschützten Endpunkt eines MCP-Servers aufzurufen. Der Server antwortet mit einem 401 und WWW-Authenticate-Headern, die auf seine Protected Resource Metadata verweisen. Der Client ruft diese Metadaten ab, um den Standort des Autorisierungsservers zu erfahren. Anschließend startet er den OAuth-2.1-Autorisierungscode-Flow mit PKCE gegenüber diesem Autorisierungsserver und leitet die nutzende Person zur Einwilligung weiter. Der Autorisierungsserver authentifiziert die Person, holt die Einwilligung ein und gibt einen Autorisierungscode zurück. Der Client tauscht diesen Code zusammen mit seinem PKCE-Verifier gegen ein Zugriffstoken aus. Bei jeder nachfolgenden Anfrage an den MCP-Server präsentiert der Client dieses Token im Authorization-Header. Der MCP-Server validiert das Token und setzt die Scopes durch.
Das ist der vollständige Autorisierungsflow. Zwei Dinge geschehen an zwei völlig unterschiedlichen Stellen. Der Autorisierungsserver behandelt Identität und Einwilligung. Der MCP-Server übernimmt die Durchsetzung. Das sind getrennte Verantwortlichkeiten und getrennte Implementierungen. Ihre Vermischung ist die Ursache der meisten Produktions-Sicherheitsprobleme, die ich bei Berichten über MCP-Deployment-Probleme sehe.
Was der Autorisierungsserver verantwortet und was der MCP-Server durchsetzt
Die Aufgabenteilung ist präzise und nicht verhandelbar. Ein Autorisierungsserver übernimmt Authentifizierung, Einwilligungserfassung und Token-Ausstellung. Die Aufgabe des MCP-Servers beginnt erst, nachdem das Token existiert.
Der Autorisierungsserver ist verantwortlich für: die Überprüfung, wer der Client ist, die Bestätigung, dass die nutzende Person den angeforderten Scopes zugestimmt hat, die Ausstellung eines signierten Zugriffstokens mit eingebetteten Scopes und – sofern zutreffend – die Ausstellung von Refresh-Tokens für lang laufende Sitzungen. Er weiß nicht und muss nicht wissen, was der MCP-Server mit dem Token tut, nachdem er es erhalten hat. Das ist nicht das Problem, das der Autorisierungsserver lösen muss.
Die Verantwortung des MCP-Servers beginnt beim Empfang des Tokens. MCP-Server müssen das Token bei jeder Anfrage validieren: die Signatur überprüfen, den Issuer kontrollieren, bestätigen, dass der Audience-Claim diesem konkreten Server entspricht, und die Scope-Claims gegenüber dem aufgerufenen Tool durchsetzen. Die Autorisierungslogik auf MCP-Server-Ebene ist kein Durchreichen. Sie ist ein aktiver Durchsetzungsschritt pro Anfrage.
Der häufige Fehler: Teams implementieren die Integration des Autorisierungsservers korrekt und gehen dann davon aus, dass der MCP-Server „autorisiert“ ist, weil er ein gültiges Token erhalten hat. Ein Token, das kryptografisch gültig ist, aber nicht die passenden Scopes für das angeforderte Tool enthält, muss abgelehnt werden. Diese Ablehnung erfolgt auf dem MCP-Server. Ein Autorisierungsserver kann mehrere MCP-Server bedienen, aber jeder Server muss eigene Scope-Anforderungen definieren und unabhängig durchsetzen. Sie können nicht mehrere Autorisierungsserver definieren und die Scope-Durchsetzung als Verantwortung anderer behandeln. Das ist sie nie.
Lebenszyklus von Zugriffstoken und Refresh-Token im MCP-Kontext
Zugriffstokens in MCP folgen dem OAuth-2.1-Modell: kurzlebig, mit Scopes versehen und bei jeder Anfrage validiert. Die Kurzlebigkeit ist nicht nur eine Empfehlung. Aembits Analyse der Spezifikation dokumentiert ausdrücklich, dass die MCP-Leitlinien serverseitige Sitzungen verbieten und eine Token-Validierung pro Anfrage vorschreiben. Damit wird ein Muster durchbrochen, zu dem Teams aus der traditionellen Webanwendungsarchitektur instinktiv greifen.
In einer sitzungsbasierten Web-App authentifizieren Sie sich einmal, und die Sitzung bleibt bestehen. Ein MCP-Client kann von dieser Annahme nicht ausgehen. Jeder Aufruf an den MCP-Server validiert das Zugriffstoken gegenüber dem Autorisierungsserver. Es gibt keine Abkürzung nach dem Motto „Wir haben diesen Nutzer bereits vor fünf Minuten geprüft“, die die Spezifikation zulässt. Dies ist eine bewusste Designentscheidung, um das Risiko zu reduzieren, dass eine kompromittierte Sitzung über einen langen Zeitraum uneingeschränkten Zugriff gewährt.
Das Refresh-Token ist für länger laufende Agent-Sitzungen vorgesehen. Wenn ein OAuth-Token mitten in einem Workflow abläuft – was bei jeder Agent-Sitzung passiert, die länger als die Token-Laufzeit dauert –, nutzt der Client ein Refresh-Token, um ein neues Zugriffstoken zu erhalten, ohne dass die nutzende Person erneut interaktiv zustimmen muss. Die anfängliche Autorisierung erfordert Anwesenheit und Einwilligung der Person. Nachfolgende Token-Aktualisierungen innerhalb derselben Sitzung nicht. Das ist das richtige Modell für KI-Agent-Workflows, die über längere Zeiträume laufen können.
Ein praktischer Hinweis zum Setup: Wenn Sie Agent-Sitzungen betreiben, die sich über Stunden erstrecken können, muss die Laufzeit des Zugriffstokens bewusst festgelegt werden. Ist sie zu kurz, aktualisieren Sie ständig und erhöhen Latenz sowie Fehlerflächen. Ist sie zu lang, untergraben Sie die Reduzierung des Schadensradius, für die die Spezifikation konzipiert wurde. Mit einer Zugriffstoken-Laufzeit von 15 bis 30 Minuten zu beginnen und bei Bedarf zu aktualisieren, ist eine sinnvolle erste Konfiguration – passen Sie sie an Ihre konkreten Anforderungen an die Sitzungsdauer an, nicht als starre Regel.
Authentifizierung und Autorisierung in MCP sind nicht dasselbe Problem
Ich sehe immer wieder, dass diese beiden Dinge vermischt werden. Das führt zu einer bestimmten Art von Produktionsfehler, die besonders ärgerlich zu debuggen ist, weil das System von außen betrachtet korrekt zu funktionieren scheint.
Authentifizierung beantwortet die Frage: Wer ist dieser MCP-Client? Der Autorisierungsserver übernimmt das. Er überprüft die Identität des Clients und der Endnutzerin oder des Endnutzers, bestätigt die Zugangsdaten und erklärt diese Identität in dem ausgestellten Token. Wenn die Authentifizierung erfolgreich ist, wissen Sie, wer die Anfrage stellt.
Autorisierung beantwortet die Frage: Was darf diese Identität tun? Der MCP-Server übernimmt das. Er übernimmt die authentifizierte Identität aus dem Token, liest die Scope-Claims und entscheidet, ob dieser konkrete Client mit diesen konkreten Scopes zu diesem Zeitpunkt dieses konkrete MCP-Tool aufrufen darf. Autorisierungsfunktionen werden auf Serverebene durchgesetzt, nicht auf der Ebene der Token-Ausstellung.
Der Fehlermodus, der in der Praxis auftritt: Ein Team implementiert die Authentifizierung korrekt, bestätigt, dass der Client ein gültiges Token erhält, implementiert aber keine Scope-Durchsetzung auf dem Server. Die Authentifizierung sieht korrekt aus. Die Verbindung funktioniert. Jedes Tool auf dem Server ist nun für jeden authentifizierten Client zugänglich – unabhängig davon, welche Scopes gewährt wurden. Das ist kein Sonderfall. Es ist die häufigste Lücke in der MCP-Autorisierung, die ich sehe, wenn Teams nach dem ersten Deployment Sicherheitsbedenken melden.
Die Spezifikation behandelt beides über getrennte Autorisierungsmechanismen, die jeweils implementiert werden müssen. Ein MCP-Client, der ein Token empfängt, wurde authentifiziert. Was dieses Token tun darf, hängt vollständig davon ab, was der MCP-Server durchsetzt, wenn er Scope- und Audience-Claims des Tokens validiert. Ein gültiges Token ist kein Freifahrtschein. Hinter jedem Tool-Aufruf muss eine Scope-Prüfung stehen.
Dort beginnt in der Regel das Ticket.
🤔 Moment.
Die MCP-Spezifikation kennzeichnet Autorisierung auf Protokollebene als optional. Aber jeder HTTP-basierte Remote-MCP-Server, der nicht vertrauenswürdigen Clients ohne Autorisierungsschicht zugänglich ist, akzeptiert Anfragen von allen, die ihn erreichen können. „Optional“ bedeutet hier, dass das Protokoll ohne Autorisierung funktioniert. Es bedeutet nicht, dass das Deployment ohne sie sicher ist. Lesen Sie die Optionalitätskennzeichnung der Spezifikation als Konnektivitätsminimum, nicht als Sicherheitsbasis.
Wo die MCP-Autorisierungsspezifikation für Enterprise-Umgebungen nicht ausreicht
Die MCP-Autorisierungsspezifikation erfüllt, was sie vorgibt zu erfüllen. Das Problem ist, dass dies nicht dasselbe ist wie das, was Enterprise-Security-Teams benötigen. Das ist keine Beschwerde über Anbieter. Es ist eine Architekturlücke zwischen dem, was die MCP-Spezifikation definiert, und dem, was die IAM-Umgebungen großer Organisationen tatsächlich erfordern.
Das aktuelle MCP-Autorisierungsmodell basiert auf OAuth 2.1 als eigenständigem Mechanismus. Es behandelt den Token-Flow zwischen Client und Server sauber. Was es nicht definiert, ist die Integration dieses Flows in bestehende Enterprise-Identitätsinfrastruktur: Microsoft Entra, Okta, interne LDAP-gestützte IdPs, SAML-Föderation oder eines der anderen Identitätssysteme, für die Enterprise-Security-Teams jahrelang Richtlinien-Durchsetzung aufgebaut haben.
Die heute verfügbaren Versionen der MCP-Autorisierungsspezifikation gehen davon aus, dass Sie entweder einen eigenständigen Autorisierungsserver betreiben oder die IdP-Integration selbst herausfinden werden. Für ein Start-up mit 15 Personen, das seinen ersten MCP-Server bereitstellt, ist das in Ordnung. Für eine Organisation, in der jedes Authentifizierungsereignis durch einen zentralen Identitätsanbieter laufen, SSO-Richtlinien erfüllen und Audit-Ereignisse in einem SIEM erzeugen muss, liefert die Basisspezifikation die Transportschicht und überlässt die Enterprise-taugliche Richtlinienschicht den Lesenden als Übung.
Die MCP-Community diskutiert diese Lücke aktiv. Die Cybersicherheitsleitlinien der NSA zu MCP warnen ausdrücklich, dass MCP derzeit keine Unterstützung für den Austausch rollenbasierter Zugriffskontrollberechtigungen bei der Instanziierung bietet, was die Durchsetzung oder Überprüfung von Zugriffsgrenzen zwischen Aufgaben in komplexen Deployments erschwert. Das ist eine bedeutende Lücke, wenn Ihre MCP-Sicherheitsstrategie von RBAC abhängt, das zur Laufzeit und nicht bei der Token-Ausstellung aufgelöst wird.
Teams, die MCP-Server im Enterprise-Maßstab bereitstellen möchten, sollten die Spezifikation als Grundlage betrachten und zusätzliche Architekturarbeit darauf planen, nicht als vollständige Lösung. Eine spezifikationskonforme Implementierung bedeutet nicht automatisch ein Enterprise-taugliches Deployment.
Integration bestehender Identitätsanbieter in das MCP-Autorisierungsmodell
Die konkrete Lücke für Enterprise-IAM-Teams liegt zwischen dem, was die Spezifikation definiert – eine abstrakte Rolle für einen Autorisierungsserver – und dem, was sie tatsächlich betreiben: einen konkreten IdP wie Entra ID oder Okta mit bestehenden Föderationsbeziehungen, Gruppenmitgliedschaften und Richtlinien-Durchsetzungspunkten.
Die Spezifikation erlaubt jedem OAuth-2.1-konformen Dienst, als Autorisierungsserver zu fungieren. Theoretisch können Entra ID oder Okta diese Rolle übernehmen. In der Praxis erfordert es Konfigurationsarbeit, die die Spezifikation nicht beschreibt, damit MCP-Clients Enterprise-IdPs korrekt entdecken und mit ihnen interagieren können. Das betrifft insbesondere die Zuordnung von Protected Resource Metadata zu IdP-spezifischen Autorisierungsendpunkten und die Abstimmung von Scopes mit Enterprise-Rollenstrukturen.
Das Risiko bei der Implementierung von MCP mit einem eigenständigen Autorisierungsserver statt mit einer Integration in den bestehenden IdP: Sie schaffen ein zweites Identitätssilo. Der Zugriff auf MCP-Tools wird dann durch Richtlinien geregelt, die außerhalb des Enterprise-IAM-Systems bestehen, separat verwaltet und geprüft werden und nicht in zentrale Prozesse der Identity Governance eingebunden sind.
Externe Autorisierung über Autorisierungsdienste von Drittanbietern oder eine enge Integration zwischen der MCP-Autorisierungsschicht und bestehenden internen IdPs ist die empfohlene Richtung für Enterprise-Umgebungen. Autorisierungsverwaltung, die an einen eigenständigen MCP-Autorisierungsserver gekoppelt ist, auf den niemand im Security-Team Einblick hat, ist genau die Art von Schatten-Credential-Store, die Enterprise-Security-Teams zu beseitigen versuchen. MCP im Enterprise-Maßstab korrekt zu implementieren bedeutet, dieses IdP-Integrationsproblem bewusst zu lösen, statt zu hoffen, dass es sich von selbst erledigt.
Warum die Absicherung von MCP für nicht menschliche Agent-Identitäten schwieriger ist
Der OAuth-2.1-Autorisierungscode-Flow setzt voraus, dass ein Mensch zur Authentifizierung und Einwilligung anwesend ist. KI-Agents und automatisierte Pipelines haben diesen Luxus nicht. Ein Agent, der um 3 Uhr morgens mitten in einem Workflow einen MCP-Server aufrufen muss, kann keinen Browser umleiten und warten, bis jemand auf „Zulassen“ klickt.
Das ist die Lücke, die die Spezifikation offenlässt. Aembits Spezifikationsanalyse identifiziert starke Agent-Authentifizierung und von der Infrastruktur bestätigte Identität als das Muster, das diese Lücke schließen kann. Die Idee: Statt interaktive Einwilligung für nicht menschliche Agents zu verlangen, bestätigt die Infrastruktur die Identität anhand überprüfbarer Merkmale der Workload selbst. Die Identität des Agents ergibt sich aus dem Ort, an dem er läuft, nicht aus Zugangsdaten, die er besitzt und potenziell preisgeben könnte.
Ein MCP-Server kann für Maschine-zu-Maschine-Flows spezifische Autorisierungsmuster verwenden, einschließlich des OAuth-2.1-Client-Credentials-Flow für nicht interaktive Szenarien. Dies erfordert jedoch durchdachtes Credential-Management: MCP-Server agieren in dieser Konfiguration als OAuth-Clients, und die für den Maschine-zu-Maschine-Zugriff ausgestellten Zugangsdaten benötigen Rotationsrichtlinien, Scope-Beschränkungen und Widerrufsverfahren, die die Spezifikation nicht vorschreibt. Die Authentifizierungskomplexität für nicht menschliche Identitäten verschwindet nicht durch die Wahl des Protokolls. Sie verlagert sich nur an eine andere Stelle. MCP für automatisierte Pipelines abzusichern, die keine interaktive Einwilligung durchführen können, ist das Implementierungsproblem, das Teams nach der Lösung der Basisspezifikation erneut von Grund auf lösen müssen, wenn sie agentische Workflows einführen.
MCP-Autorisierungs-Best-Practices, die die häufigsten Fehler wirklich verhindern
Jeder Punkt unten benennt einen konkreten Fehlermodus und die Prüfung oder Designentscheidung, die ihn verhindert. Das sind keine allgemeinen Sicherheitsempfehlungen. Sie basieren auf den Anforderungen der Spezifikation und darauf, was scheitert, wenn Teams Schritte auslassen.
Token-Validierung pro Anfrage durchsetzen, niemals sitzungsbasierte Vertrauenswiederverwendung
Die Spezifikation schreibt dies vor. Der Fehlermodus: Ein Team, das mit sitzungsbasierten Web-Apps vertraut ist, speichert „Dieser Client war vor fünf Minuten autorisiert“ im Cache und überspringt die erneute Validierung. Wenn das Token widerrufen wird oder abläuft, akzeptiert der MCP-Server weiterhin Anfragen, bis der Cache geleert wird. Validieren Sie das Token bei jedem Aufruf an den MCP-Server, nicht nur einmal beim Sitzungsstart.
Scope-Durchsetzung auf Tool-Ebene implementieren, nicht nur beim Aufbau der Verbindung
Ein Token mit gültiger Authentifizierung, aber ohne Tool-spezifische Scopes, muss beim Tool-Aufruf abgelehnt werden. Der häufige Fehler: Es wird geprüft, ob das Token gültig ist, bestätigt, dass der Client verbunden ist, und danach jeder Tool-Aufruf erlaubt. MCP-Server müssen bei jeder Anfrage Scope-Prüfungen für das konkret aufgerufene Tool implementieren. Ein Token mit Lese-Scope darf kein Schreib-Tool aufrufen können, auch wenn die Verbindung erfolgreich aufgebaut wurde.
Dynamische Client-Registrierung über RFC 7591 unterstützen
MCP-Clients sollten die programmatische Registrierung unterstützen, statt zu verlangen, dass alle Clients manuell vorregistriert werden. Der Fehlermodus ohne dies: Sie können neue Agent-Clients nicht im großen Maßstab onboarden, ohne für jeden Client einen manuellen Konfigurationsschritt durchzuführen. Erlauben Sie MCP-Clients die dynamische Registrierung und stellen Sie sicher, dass dynamisch registrierte Clients angemessen eingeschränkte Scopes statt pauschalem Zugriff erhalten.
PKCE für alle Autorisierungscode-Flows verlangen, ohne Ausnahmen
Wenn Sie PKCE für einen heute scheinbar „sicheren“ Flow überspringen, lassen Sie einen Vektor zum Abfangen von Autorisierungscodes offen. Die Spezifikation verlangt PKCE für öffentliche Clients. Behandeln Sie es als universelle Anforderung statt als Einzelfallentscheidung. Jeder neue Autorisierungsflow in Ihrer Implementierung sollte standardmäßig PKCE enthalten.
Tokens im Authorization-Header übertragen, nicht im Request-Body oder Query-String
Dies ist ein grundlegender Punkt der Transporthygiene, der häufiger übersehen wird, als er sollte. Ein Zugriffstoken in einem Query-String erscheint in Server-Logs, dem Browserverlauf und Referrer-Headern. Im Header nicht. Jede Implementierung der Token-Übertragung von Clients an den MCP-Server sollte prüfen, dass der Header der Übertragungsmechanismus ist.
MCP-Autorisierung ersetzt keine nachgelagerten API-Zugriffskontrollen
Dies ist die teuerste Fehlannahme, die ich bei der Bewertung der eigenen Sicherheitsstrategie nach der Implementierung von MCP-Autorisierung sehe. MCP-Autorisierung steuert den Zugriff auf den MCP-Server und seine Tools. Die angebundenen Dienste, die diese Tools aufrufen – Ihre internen APIs, Datenbanken und SaaS-Systeme –, benötigen weiterhin eigene Zugriffskontrollen. Ein Token, das einen Tool-Aufruf auf der MCP-Ebene autorisiert, autorisiert nicht automatisch alles, was dieses Tool nachgelagert tun kann. Die zentrale MCP-Autorisierungsschicht und die Autorisierung nachgelagerter Dienste sind unabhängige Durchsetzungspunkte, die jeweils implementiert werden müssen. Teams, die die MCP-Schicht implementieren und sich danach für sicher erklären, erwartet eine unangenehme Überraschung.
Refresh-Tokens mit Rotation für lang laufende Agent-Sitzungen verwenden
Das Ablaufen eines Zugriffstokens während eines mehrstufigen Agent-Workflows ist ein Zuverlässigkeitsproblem, auf das Teams früh stoßen. Die korrekte Architektur: Stellen Sie bei der initialen Autorisierung ein Refresh-Token aus und verwenden Sie es, um neue Zugriffstokens zu erhalten, ohne den Workflow zu unterbrechen. Nutzen Sie Token-Rotation, sodass jede Aktualisierung das vorherige Refresh-Token ungültig macht und den Schadensradius eines gestohlenen Refresh-Tokens begrenzt.
📊 In der Praxis:
Die Token-Validierung pro Anfrage gegenüber dem Autorisierungsserver ist das, was die Spezifikation vorschreibt – und sie durchbricht direkt das verbreitete sitzungsbasierte Vertrauensmuster, das Teams aus der traditionellen Web-Authentifizierung übernehmen. Die Implementierungsprüfung ist konkret: Wenn Ihr MCP-Server irgendeinen Codepfad enthält, bei dem ein bereits gesehenes Client-Token die Validierung umgeht, weil „wir es bereits geprüft haben“, verletzt dieser Codepfad gleichzeitig die Spezifikation und Ihre Sicherheitsstrategie. Entfernen Sie ihn.
Wer MCP-Autorisierung nutzt und was tatsächlich kontrolliert werden soll
Drei Arten von Teams stoßen in der Praxis auf MCP-Autorisierungsprobleme, und jede versucht, etwas anderes zu kontrollieren.
KI-Plattformteams, die Tools für den Aufruf durch Agents entwickeln, möchten in erster Linie über Scopes und Rollen steuern, welche MCP-Clients auf welche Tools zugreifen können. Der erste MCP-Server, den sie bereitstellen, startet in der Regel ohne Scope-Kontrollen über „authentifiziert oder nicht“ hinaus. Das Problem tritt auf, wenn sie einem schreibgeschützten Analyse-Agent erlauben müssen, Tool-Ausgaben zu sehen, ihn aber daran hindern wollen, Schreiboperationen aufzurufen. Der Autorisierungscode-Flow mit einem passenden Scope-Design löst dies – aber er erfordert, dass Sie vor dem Aufbau des Servers über eine Scope-Taxonomie nachdenken, nicht erst danach. Die MCP-Spezifikation liefert den Mechanismus. Sie müssen die Scopes definieren, deren Durchsetzung sinnvoll ist.
Security- und IAM-Teams wollen Richtlinien zentralisieren, damit sie nicht für jedes MCP-Deployment einen separaten Credential-Store verwalten. Ihr Ziel ist die OAuth-2.1-IdP-Integration: Jedes MCP-Token sollte auf ein Identitätsereignis im zentralen Identitätsanbieter zurückführbar sein, nicht auf einen eigenständigen Autorisierungsserver. Sie möchten kurzlebige Tokens, klare Audience-Claims für Ressourcenserver in jedem Token und die Möglichkeit, Zugriff durch Widerruf der IdP-Sitzung zu entziehen. Breite, lang laufende Zugangsdaten, die nicht in die zentrale IAM-Governance eingebunden sind, sind genau das, was sie beseitigen möchten. MCP-Autorisierung liefert das Muster. Die Föderation mit dem bestehenden IdP umzusetzen, ist die eigentliche Implementierungsarbeit.
SaaS-Anbieter und Infrastrukturanbieter, die MCP-Server externen Kunden bereitstellen, benötigen Enterprise-SSO-Integration und automatisierte Client-Konfiguration über Metadaten zum Standort des Autorisierungsservers. Die Agents ihrer Kunden müssen den Autorisierungsserver entdecken, sich dynamisch registrieren und angemessen eingeschränkte Tokens erhalten können – ohne manuellen Onboarding-Schritt pro Kunde. RFC 8414 und RFC 9728 sind für diesen Anwendungsfall keine theoretischen Abhängigkeiten. Sie sind der Mechanismus, der programmatisches Onboarding ermöglicht. Ohne sie ist jeder neue Kunde eine manuelle Konfiguration.
Für Teams, die Automatisierungs-Workflows auf MCP-autorisierten Servern aufbauen, gilt dasselbe Token- und Scope-Modell innerhalb der Implementierung. Ein Workflow, der auf 401-Antworten von MCP-Servern reagiert, den OAuth-2.1- plus PKCE-Austausch zentral steuert und Aufrufe mit dem resultierenden Token ausführt, ist ein saubereres Muster, als die Authentifizierungsbehandlung in jede einzelne Integration einzubauen. Latenode unterstützt dies durch JavaScript-Nodes, die die Token-Austauschlogik verarbeiten können, sowie durch seine über 5.500 Integrationen mit automatischem OAuth für die zugrunde liegenden Dienstverbindungen – ein Setup, das ein mehrwöchiges Authentifizierungsprojekt zu etwas macht, das Sie an einem Nachmittag bereitstellen können, sobald Sie den Flow einmal modelliert haben.
