Bei MCP gibt es drei Rollen. Der MCP-Server stellt Werkzeuge und Ressourcen bereit. Der MCP-Client ist in eine Host-Anwendung eingebettet, etwa in einen Chat-Client oder eine Entwicklungsumgebung. Das Sprachmodell entscheidet im Dialog, welche Werkzeuge aufgerufen werden. Wie ein MCP-Server mit Spring AI umgesetzt wird, beschreibt der Beitrag Spring AI MCP-Server: Spring-Dokumentation für LLMs bereitstellen.

Greift ein Werkzeug auf echte Systeme und Daten zu, muss der Server wissen, in wessen Namen der Aufruf erfolgt und ob dieser Zugriff erlaubt ist. Ein frei zugänglicher MCP-Server würde jedem Modell und jedem Client den vollen Zugriff auf die dahinterliegenden Systeme öffnen. Deshalb behandelt MCP den Server als geschützte Ressource (Protected Resource) und verlangt für Aufrufe ein gültiges Access Token.

Die erste MCP-Version aus dem November 2024 kannte noch keine Autorisierung. Erst die späteren Revisionen haben OAuth als Verfahren aufgenommen. Keycloak unterstützt die Fassung 2025-03-26 vollständig, neuere Revisionen sind als experimentell gekennzeichnet.

Im OAuth-Modell ist der MCP-Server die geschützte Ressource, der MCP-Client der OAuth-Client und Keycloak der Autorisierungsserver. Der Ablauf folgt dem bekannten OAuth-Muster: Der Client holt sich bei Keycloak ein Access Token, der MCP-Server prüft dieses Token bei jedem Aufruf. Wie eine Spring Boot Anwendung als Resource Server Keycloak Tokens prüft und die Rollen auswertet, beschreibt der Beitrag OAuth 2.0 Resource Server: Keycloak Rollen auf Spring Security Authorities mappen.

Neu ist vor allem, wie Client und Server zueinander finden, ohne dass alles von Hand konfiguriert werden muss. Der Client kennt zunächst nur die Adresse des MCP-Servers. Über die Protected Resource Metadata (RFC 9728) teilt der Server mit, welcher Autorisierungsserver für ihn zuständig ist. Von dort liest der Client die Authorization Server Metadata (RFC 8414) und kennt damit die Endpunkte für den OAuth-Flow. Keycloak stellt diese Metadaten bereit, sodass ein passend konfigurierter MCP-Client den Anmeldefluss selbstständig aufbauen kann.

Ein zentrales Thema ist, dass ein Token nur für den MCP-Server gilt, für den es ausgestellt wurde. Andernfalls ließe sich ein Token, das für einen harmlosen Server gedacht war, gegen einen anderen Server mit mehr Rechten verwenden. Ab der MCP-Fassung 2025-06-18 muss das Token daher an die Zieladresse gebunden sein, erkennbar am aud-Claim.

Keycloak bietet dafür zwei Wege. Ohne Resource Indicators wird mit Client Scopes und einem Audience Mapper gearbeitet: Ein Scope wie mcp:tools trägt über den Mapper die URL des MCP-Servers als Audience in das Token. Mit Resource Indicators (RFC 8707) gibt der Client beim Anmelden einen resource-Parameter an. Keycloak gleicht diesen mit der am Client hinterlegten resource_url ab und setzt den aud-Claim entsprechend. Resource Indicators sind in Keycloak noch als experimentelles Feature umgesetzt und müssen über ein Feature-Flag aktiviert werden.

Damit ein MCP-Client bei Keycloak auftreten kann, muss er als Client bekannt sein. Das kann klassisch von Hand geschehen. Für Szenarien, in denen die konkreten Clients vorab nicht feststehen, gibt es zwei weitere Wege.

Die Dynamic Client Registration (RFC 7591) erlaubt es einem Client, sich selbst zu registrieren. Neuer ist das Client ID Metadata Document: Der Client wird nicht über eine vorab vergebene ID, sondern über eine URL identifiziert, unter der seine Metadaten liegen. Keycloak lädt dieses Dokument und leitet daraus die Client-Konfiguration ab. Gesteuert wird das über ein Client Profile mit dem Executor client-id-metadata-document und eine Client Policy, die greift, sobald die client_id als URL auftritt. An solche URLs stellt Keycloak strikte Anforderungen, etwa HTTPS, einen Pfadanteil sowie den Verzicht auf Query- und Fragment-Bestandteile.

Werkzeuge wie Claude Code, Claude Desktop und VS Code nutzen dieses Verfahren bereits. Für ChatGPT ist das Metadaten-Format derzeit nicht kompatibel, da es an einer Stelle von der Spezifikation abweicht. Auch das Client ID Metadata Document ist in Keycloak noch experimentell und über ein Feature-Flag zu aktivieren.

Die Autorisierung von MCP ist jung und noch in Bewegung. Innerhalb kurzer Zeit sind mehrere Fassungen der Spezifikation erschienen, und ein Teil der benötigten Funktionen ist in Keycloak als experimentell markiert.

Für einen produktiven Einsatz bedeutet das vor allem drei Dinge. Die genutzte MCP-Fassung und die zugehörigen Keycloak-Feature-Flags sollten bewusst gewählt und dokumentiert werden. Das Audience-Binding muss sauber konfiguriert sein, damit Tokens nicht über ihren vorgesehenen Server hinaus gelten. Und es ist mit weiteren Änderungen zu rechnen, Aktualisierungen gehören also fest in den Betriebsplan.

Wer Keycloak ohnehin als zentralen Identitäts- und Zugriffsdienst betreibt, kann MCP-Server in dieselbe bestehende Autorisierung einbinden, statt eine eigene Lösung aufzubauen. Die vollständigen Konfigurationsschritte beschreibt die offizielle Keycloak-Dokumentation.

Wie sich Keycloak absichern und in eigene Anwendungen einbinden lässt und wie KI-Systeme sauber an bestehende Architekturen angebunden werden, vertiefen wir in unseren Schulungen.