01Rollenmodell: MCP-Server als Resource Server
Seit der Revision 2025-06-18 agiert ein geschützter MCP-Server als OAuth-2.1-Resource-Server: Er nimmt Access Tokens entgegen und validiert sie, stellt sie aber nicht selbst aus; der MCP-Client agiert als OAuth-Client im Auftrag des Nutzers. Der Authorization Server ist eine getrennte Rolle – er darf mit dem Resource Server gehostet werden, seine Implementierung liegt aber außerhalb der Spezifikation. Das war nicht immer so: Die Revision 2025-03-26 behandelte den MCP-Server de facto als Authorization Server und Resource Server in einem, mit Default-Endpunkten /authorize, /token und /register direkt am MCP-Server. Die formale Trennung entlastet Server-Betreiber und erlaubt etablierte Identity-Provider statt selbstgebauter Token-Ausgabe.
02Discovery-Kette: RFC 9728 und RFC 8414
Der Client findet den zuständigen Authorization Server zur Laufzeit statt per Konfiguration: Auf einen Request ohne gültiges Token antwortet der MCP-Server mit 401 Unauthorized und verweist im WWW-Authenticate-Header auf seine Protected Resource Metadata (RFC 9728) – ein Pflichtdokument, dessen Feld authorization_servers mindestens einen Authorization Server nennt. Von dort lädt der Client die Authorization Server Metadata nach RFC 8414 (/.well-known/oauth-authorization-server) mit Authorize-, Token- und Registrierungs-Endpunkt; erst dann beginnt der eigentliche OAuth-2.1-Flow. Diese Runtime-Discovery ersetzt hartkodierte Konfiguration – entscheidend für Agenten, die Tools erst zur Laufzeit zugewiesen bekommen. Die Revision 2025-11-25 ergänzt OpenID Connect Discovery und einen .well-known-Fallback ohne Header; die Revision 2026-07-28 fügt die Issuer-Validierung nach RFC 9207 gegen Mix-up-Angriffe hinzu.
03Client-Registrierung: RFC 7591 und CIMD
Weil beliebige MCP-Clients auf beliebige Server treffen, skaliert manuelle Client-Registrierung nicht. Die Revision 2025-06-18 empfiehlt deshalb (SHOULD) Dynamic Client Registration nach RFC 7591: Der Client registriert sich selbst am Registrierungs-Endpunkt und erhält eine eigene client_id – in der Praxis meist als Public Client ohne Client-Secret; Alternativen sind eine fest hinterlegte Client-ID oder die manuelle Eingabe. Die Revision 2026-07-28 erklärt DCR allerdings für deprecated und setzt auf die mit der Revision 2025-11-25 eingeführten Client ID Metadata Documents (CIMD): URL-basierte Client-Identitäten. Zugleich stellt sie klar, dass gespeicherte Client-Credentials an den ausstellenden Authorization Server gebunden sind und nicht über Server-Grenzen hinweg wiederverwendet werden dürfen. DCR funktioniert aus Kompatibilitätsgründen übergangsweise weiter – Neuimplementierungen sollten beide Wege kennen.
04OAuth-2.1-Grundregeln: PKCE, Header, kurze Laufzeiten
OAuth 2.1 räumt mit unsicheren Altlasten von OAuth 2.0 auf: Implicit Grant und Password Grant entfallen, Redirect-URIs werden nur noch exakt gematcht, und PKCE ist Pflicht – MCP-Clients MÜSSEN PKCE implementieren, in der Praxis mit der S256-Challenge-Methode statt „plain“. Access Tokens gehören als Bearer-Token in den Authorization-Header jedes einzelnen Requests und dürfen nie im URI-Query-String stehen; alle Authorization-Server-Endpunkte laufen über HTTPS, Redirect-URIs sind auf localhost oder HTTPS beschränkt. Refresh Tokens für Public Clients müssen nach OAuth 2.1 sender-constrained oder Einmal-Tokens mit Rotation sein. Gängige Praxisempfehlungen ergänzen kurzlebige Access Tokens von wenigen Minuten sowie Reuse-Detection, die bei Wiederverwendung eines alten Refresh Tokens die gesamte Token-Familie widerruft.
05Audience-Bindung (RFC 8707) und Token-Passthrough-Verbot
Ein Token muss für genau einen MCP-Server ausgestellt sein: Clients MÜSSEN den resource-Parameter nach RFC 8707 in Authorization- und Token-Request senden und darin die kanonische URI des Ziel-Servers angeben; der Server MUSS prüfen, ob er die intended audience ist, und fremde oder abgelaufene Tokens mit 401 ablehnen. Ebenso strikt ist das Passthrough-Verbot: Ein MCP-Server DARF das vom Client erhaltene Token NICHT an nachgelagerte APIs weiterreichen, sondern agiert dort als eigener OAuth-Client mit eigenem Token. Sonst droht das Confused-Deputy-Problem – der Server handelt als verwirrter Stellvertreter mit fremden Berechtigungen, und Rate Limiting, Monitoring und Audit-Trail der Downstream-API laufen ins Leere. Proxy-Server mit statischer Client-ID MÜSSEN zudem für jeden dynamisch registrierten Client eine eigene Nutzer-Zustimmung einholen, weil wiederverwendete Consent-Cookies sonst Authorization Codes an Angreifer leiten.
06MCP07 in der Praxis: Befund und Kontrollen
Die OWASP MCP Top 10 (Version v0.1, Beta – kein finaler Standard) führen das Themenfeld als MCP07 „Insufficient Authentication & Authorization“. Der Praxisbefund ist ernüchternd: Trend Micro fand 2025 insgesamt 492 MCP-Server ohne Authentifizierung und Transportverschlüsselung offen im Internet, das Astrix-Audit zählte 53 Prozent statische API-Keys bei nur 8,5 Prozent OAuth, und CVE-2025-6514 im npm-Paket mcp-remote (CVSS 9,6) zeigte, dass schon manipulierte OAuth-Discovery-Felder Codeausführung auslösen können. Wirksame Kontrollen setzen an der Spezifikation an: OAuth 2.1 mit PKCE und getrenntem Authorization Server, kurzlebige, audience-gebundene Tokens statt Passthrough – bei Upstream-Aufrufen Token Exchange nach RFC 8693 –, Per-Client-Consent in Proxies und MCP-Server als eigene Non-Human Identity im IAM. Zwei Prüffragen für Revision und Vorstand: Läuft irgendwo in der Kette ein Token-Passthrough – und wie lange lebt ein Agenten-Token?
