Token-Passthrough und der Confused Deputy bei MCP-Servern, die andere APIs aufrufen

Worum es geht

Das Dokument MCP Security Best Practices beschreibt mehrere Angriffe auf Server, die zwischen einem Client und einer Drittanbieter-API sitzen.

Token-Passthrough wird dort als Anti-Pattern definiert: Der Server nimmt ein Token vom Client entgegen, ohne zu prüfen, ob es für den MCP-Server ausgestellt wurde, und reicht es an die nachgelagerte API weiter. Das Dokument stellt fest, dass die Autorisierungsspezifikation dies ausdrücklich verbietet.

Confused Deputy: Ein MCP-Proxy-Server, der bei einem Drittanbieter-Autorisierungsserver eine statische Client-ID zusammen mit dynamischer Client-Registrierung und einem von einer früheren Genehmigung hinterlassenen Consent-Cookie verwendet, kann so missbraucht werden, dass ein bösartiger Client einen Autorisierungscode ohne eine erneute Zustimmung der nutzenden Person erhält. Der Server ist der Deputy; seine vertrauenswürdige Position wird von jemand anderem geliehen.

Warum es wichtig ist

Beide Muster löschen die Grenze aus, die es erlaubt nachzuvollziehen, wer was getan hat. Bei Passthrough sieht die nachgelagerte API ein Token, aber nicht die eigenen Prüfungen, Rate-Limits oder das Audit-Protokoll des MCP-Servers; ein anderswo gestohlenes Token kann über den Server erneut eingesetzt werden. Bei einem Confused Deputy wird die frühere Zustimmung der nutzenden Person für einen Client wiederverwendet, den sie nie genehmigt hat. Agenten verschärfen dies, weil sie Tools in Maschinengeschwindigkeit aufrufen und selten Zustimmungsbildschirme vor eine Person bringen.

So wird es angewendet

• Jedes eingehende Token validieren: Aussteller, Audience (muss den eigenen Server benennen), Ablauf und Scope. Token ablehnen, die für eine andere Ressource ausgestellt wurden.
• Für den eigenen Server separate nachgelagerte Zugangsdaten beschaffen und sie ausdrücklich der aufrufenden Person zuordnen; das eingehende Token nie weiterleiten.
• Bei Proxy-Servern, die vorgelagert eine statische Client-ID verwenden, die Zustimmung der nutzenden Person pro Client am eigenen Server einholen, bevor an den Drittanbieter-Autorisierungsserver weitergeleitet wird, und ein Consent-Cookie nicht als Ersatz dafür zulassen.
• Redirect-URIs exakt gegen die registrierten abgleichen.
• Die engstmöglichen Scopes anfordern; die Anleitung nennt Scope-Minimierung unter ihren Massnahmen.
• Den aufrufenden Client und die aufrufende Person für jeden nachgelagerten Aufruf protokollieren.

Stolpersteine

• «Das Token hat nachgelagert funktioniert» als Beweis dafür zu nehmen, dass es für den eigenen Server bestimmt war.
• Ein einziges gemeinsam genutztes Dienst-Credential für alle Aufrufenden, das jede nutzende Person so mächtig macht wie die am stärksten privilegierte.