MCP-Server absichern: OAuth, Audience-Bindung & der verwirrte Stellvertreter
- Verstehen, warum ein entfernter (HTTP-)MCP-Server ein OAuth-2.1-Resource-Server ist und nicht nur ein API-Key-Endpunkt
- Den Discovery-Handshake nachvollziehen: 401 → Protected Resource Metadata → Authorization Server Metadata → Token
- Die Audience-Bindung von Tokens (RFC 8707) erklären und warum sie verhindert, dass das Token eines Dienstes bei einem anderen funktioniert
- Die Falle des verwirrten Stellvertreters benennen und die eine Regel, die sie schließt: niemals das Token eines Clients an eine vorgelagerte API durchreichen
- Eine kurze Härtungs-Checkliste anwenden, bevor du einen MCP-Server im Internet freigibst
MCP hat sich von einer Neuheit zur Standardart entwickelt, mit der Agenten Werkzeuge erreichen — was bedeutet, dass MCP-Server nun vor echten Daten und echten Aktionen sitzen. Ein lokaler Server, den du über STDIO startest, vertraut seiner Umgebung: Er liest Zugangsdaten aus Umgebungsvariablen, und es gibt keine Netzwerkgrenze zu verteidigen. Sobald du denselben Server entfernt (HTTP) betreibst, kann jeder, der die URL erreicht, versuchen, ihn aufzurufen. Das verwandelt ihn in ein Autorisierungsproblem, und die MCP-Spezifikation beantwortet das mit OAuth 2.1 — nicht mit einem selbstgebauten API-Key-Schema.
Diese Seite behandelt den entfernten Fall. Wenn dein Server nur STDIO nutzt, sagt die Spezifikation ausdrücklich: Folge dem OAuth-Ablauf nicht — hole die Zugangsdaten aus der Umgebung und mach weiter.
Die drei Rollen
OAuth teilt das Problem auf drei Parteien auf. MCP bildet sich sauber darauf ab:
Der entscheidende gedankliche Wechsel: Der MCP-Server kümmert sich niemals selbst um den Login. Er validiert nur Tokens, die jemand anderes ausgestellt hat. Diese Trennung ist es, die es dir erlaubt, einen fertigen Identitätsanbieter vor einen selbst geschriebenen Server zu stellen.
Der Discovery-Handshake
Ein Client sollte nicht vorkonfiguriert wissen müssen, wo er sich authentifizieren soll. MCP macht die Discovery automatisch, ausgelöst durch ein 401:
- Die allererste Anfrage geht nackt hinaus. Der Server weist sie mit HTTP 401 Unauthorized und einem WWW-Authenticate-Header ab, der auf seine Resource-Metadata-URL verweist.
- Er ruft per GET /.well-known/oauth-protected-resource auf dem Server ab. Das Feld authorization_servers des Dokuments benennt mindestens einen Authorization Server, den der Client verwenden kann.
- Er ruft per GET /.well-known/oauth-authorization-server des AS ab, um die Authorize- und Token-Endpunkte sowie die unterstützten Fähigkeiten zu erfahren.
- Wenn der Client keine Client-ID für diesen AS hat, kann er per POST /register eine ohne menschliches Zutun beschaffen — entscheidend, weil ein Client nicht jeden MCP-Server im Voraus kennen kann.
- Der Client erzeugt einen PKCE-Verifier/-Challenge, öffnet den Browser zur Authorize-URL inklusive des resource-Parameters, der Benutzer stimmt zu, und der Client tauscht den zurückgegebenen Code (mit dem Verifier) gegen ein Access-Token ein.
- Nun trägt jede Anfrage Authorization: Bearer <token>. Der Server validiert es und antwortet.
Beachte, dass es auf der Client-Seite keine fest verdrahtete Auth-Konfiguration gibt — das 401 bootet alles hoch. Genau das ist der Sinn: Ein Agent kann sich mit einem Server verbinden, den er noch nie gesehen hat, und herausfinden, wie er sich authentifiziert.
Audience-Bindung: die tragende Regel
Hier ist der Fehlermodus, den die Audience-Bindung verhindern soll. Angenommen, ein Benutzer hat ein Token, das für calendar.example.com ausgestellt wurde. Ein bösartiger (oder einfach nachlässiger) MCP-Server unter evil.example.com bringt den Client dazu, dieses Token an ihn zu senden. Wenn evil es akzeptiert, kann er sich nun umdrehen und die Kalender-API im Namen des Benutzers aufrufen. Das Token eines Dienstes hat bei einem anderen funktioniert. Die Sicherheitsgrenze von OAuth ist gerade zusammengebrochen.
Die Lösung sind Resource Indicators (RFC 8707):
- Sowohl bei der Autorisierungsanfrage als auch bei der Token-Anfrage MUSS der Client einen resource-Parameter einschließen, der auf die kanonische URI des MCP-Servers gesetzt ist, den er aufrufen will — z. B. resource=https://mcp.example.com. Er sendet ihn auch dann, wenn er unsicher ist, ob der AS ihn unterstützt.
- Wo unterstützt, stempelt der AS das Token so, dass es nur für diesen spezifischen Resource Server gültig ist.
- Bevor er irgendeine Arbeit verrichtet, MUSS der MCP-Server prüfen, dass das Token für IHN ausgestellt wurde — indem er den Audience-Claim (RFC 9068) prüft. Ein Token, das für irgendjemand anderen erzeugt wurde, bekommt ein 401, Punkt.
Resource-Parameter bei der Autorisierungsanfrage (URL-kodiert)
&resource=https%3A%2F%2Fmcp.example.com
Kanonische URIs sind strikt: https://mcp.example.com und https://mcp.example.com:8443/mcp sind gültig; mcp.example.com (kein Schema) und https://mcp.example.com#frag (Fragment) sind es nicht. Bevorzuge für die Interoperabilität die Form ohne abschließenden Schrägstrich.
Der verwirrte Stellvertreter: das Token niemals durchreichen
Das ist der Fehler, der einen wohlmeinenden MCP-Server in den Proxy eines Angreifers verwandelt. Es ist dasselbe Problem des verwirrten Stellvertreters aus der Agenten-Sicherheit, zugespitzt auf eine konkrete Regel.
Ein MCP-Server muss oft eine vorgelagerte API aufrufen (GitHub, einen Datenbankdienst, ein anderes SaaS). Die Versuchung besteht darin, das Token zu nehmen, das der Client dir gereicht hat, und es weiterzuleiten. Tu das nicht. Die Spezifikation ist unmissverständlich: Der MCP-Server DARF NICHT das Token durchreichen, das er vom Client erhalten hat.
Warum das gefährlich ist: Das Token des Clients wurde für deinen Server als seine Audience ausgestellt. Wenn du es weiterleitest, vertraut die vorgelagerte API ihm womöglich, als käme es von dir, oder nimmt an, du hättest es bereits validiert — und nun verrichtet ein Token, das für einen Hop bestimmt war, Arbeit zwei Hops entfernt, außerhalb des Zustimmungsmodells von irgendjemandem.
- Wenn dein MCP-Server eine vorgelagerte API aufruft, agiert er als SEPARATER OAuth-Client gegenüber dieser API und beschafft sein EIGENES Token vom vorgelagerten Authorization Server. Zwei unabhängige Tokens, zwei unabhängige Audiences. Das Token des Clients endet an deiner Tür.
Eine Pre-Flight-Härtungs-Checkliste
Bevor ein entfernter MCP-Server das öffentliche Internet berührt:
- Alle AS-Endpunkte MÜSSEN HTTPS sein. Redirect-URIs MÜSSEN HTTPS oder localhost sein — sonst nichts.
- Weise jedes Token zurück, das nicht ausdrücklich für diesen Server ausgestellt wurde. Das ist die eine Prüfung, die die dienstübergreifende Token-Wiederverwendung stoppt.
- Clients MÜSSEN PKCE verwenden, damit ein abgefangener Autorisierungscode ohne den passenden Verifier nutzlos ist.
- Der AS MUSS Redirect-URIs exakt gegen vorregistrierte Werte abgleichen, und Clients SOLLTEN den state-Parameter verwenden und verifizieren — beides schützt vor Open-Redirect-Phishing.
- Stelle kurzlebige Access-Tokens aus, um den Schaden eines Lecks zu begrenzen; bei öffentlichen Clients rotiere die Refresh-Tokens. Speichere Tokens sicher und logge sie niemals.
- Tokens gehören in den Authorization-Header, niemals in den Query-String, wo sie in Logs und Referrern landen würden.
- Die Audience-Bindung ist das Transport-Tor; wende trotzdem Least Privilege, Sandboxing und Human-in-the-Loop aus /docs/security/securing-agents an. Auth sagt WER — sie sagt nicht, dass die Anfrage sicher ist.
Prüfe dich selbst
Prüfe dich selbst
0/4Quellen & weiterführende Literatur
- MCP-Autorisierungsspezifikation (2025-06-18) — der normative Ablauf, die Rollen und die MUST/SHOULD-Anforderungen, die diese Seite zusammenfasst.
- MCP Security Best Practices — Token-Durchreichung, verwirrter Stellvertreter und warum sie verboten sind.
- RFC 8707 — Resource Indicators for OAuth 2.0 — der
resource-Parameter und die Audience-Bindung. - RFC 9728 — OAuth 2.0 Protected Resource Metadata — wie ein Resource Server seine Authorization Server bekanntgibt.
- RFC 8414 — OAuth 2.0 Authorization Server Metadata und RFC 7591 — Dynamic Client Registration.
- OAuth 2.1 draft — PKCE, Kommunikationssicherheit und Anforderungen an die Token-Handhabung.
- Verwandtes auf AILmanac: Agenten & Werkzeuge absichern · Prompt Injection · MCP in Claude Code.