Authentifizierung & Autorisierung

Ein MCP-first System braucht eine präzise Sicherheitsarchitektur. Nicht jeder Client darf jedes Tool sehen. Nicht jeder Agent darf jedes Tool aufrufen. Nicht jede Aktion darf autonom ausgeführt werden. Nicht jede Information darf in den KI-Kontext gelangen.

Dafür ist es notwendig, verschiedene Identitätstypen klar zu trennen und für jeden den passenden Authentifizierungsmechanismus zu definieren.

Die fünf Identitäten

Human User

Ein echter Benutzer des Systems, mit einer persönlichen Identität und rollengebundenen Rechten. Typische Ausprägungen: Admin, Mitarbeiter, Kunde, Projektmanager, Support-Mitarbeiter, Geschäftsführer.

Der Human User ist die Basis-Identität. Alle delegierten Kontexte beziehen sich letztlich auf ihn.

MCP Client

Die Anwendung, die mit dem MCP-Server verbunden ist. Der MCP Client ist kein Benutzer, sondern ein technischer Akteur mit eigenem Vertrauensniveau.

Beispiele: Claude Desktop, interne AI-App, eigene Mobile App, eigener Agent Worker, externer Integrationsclient.

Der Client erhält nur die Tools zu sehen, die seinem Vertrauensniveau und den konfigurierten Scopes entsprechen.

Agent Identity

Der konkrete Agent oder Workflow, der handelt. Ein Agent ist nicht identisch mit dem Client, der ihn ausführt, er hat eine eigene, beschriebene Identität mit eingeschränkten Fähigkeiten.

Beispiele: Sales Assistant, Payroll Assistant, Support Agent, DevOps Agent, Reporting Agent, Personal Assistant.

Delegated User Context

Der Delegated User Context stellt sicher, dass ein Agent genau dann und genau so viel darf, wie der Benutzer, in dessen Auftrag er handelt. Der Geschäftsführer darf Gehaltsdaten sehen, ein Sales Assistant Agent darf diese Daten trotzdem nicht in seinen Kontext bekommen.

Service Identity

Für Backend-zu-Backend-Prozesse ohne direkten Benutzer-Kontext. Service Identities sind technische Akteure mit fest definierten, engen Scopes.

Beispiele: Import Worker, Scheduled Job, Sync Worker, Monitoring Agent, Billing Worker.

Authentifizierung für Menschen

Menschliche Benutzer authentifizieren sich über etablierte Verfahren. Die Wahl des Verfahrens richtet sich nach Sicherheitsanforderung und Kontext:

• E-Mail + Passwort, Basiszugang, immer mit 2FA kombinieren
• Passkeys, phishing-resistente Alternative zu Passwörtern, bevorzugt einsetzen
• TOTP / 2FA, zweiter Faktor für alle sensiblen Bereiche
• SSO, für Unternehmensumgebungen mit zentraler Identitätsverwaltung
• OAuth / OpenID Connect, für Drittanbieter-Logins und delegierte Zugänge

Authentifizierung für MCP-Clients

MCP-Clients werden über OAuth 2.1 mit Authorization Code Flow und PKCE authentifiziert. Das verhindert Code-Injection-Angriffe und ist für öffentliche Clients (ohne sicheres Client-Secret) geeignet.

Weitere Anforderungen:

• Kurze Access-Token-Laufzeiten, minimiert das Schadenspotenzial bei Token-Leaks
• Refresh Token Rotation, jedes Einlösen eines Refresh Tokens erzeugt ein neues; das alte wird sofort ungültig
• Client Allowlist, für sensible Systeme werden nur explizit registrierte Clients zugelassen; Dynamic Client Registration ist eingeschränkt oder deaktiviert
• Redirect-URI-Validierung, nur vorab registrierte URIs werden akzeptiert; offene Weiterleitungen sind ein häufiger Angriffsvektor
• Token Binding, wo technisch möglich, wird der Token an den Client gebunden

Authentifizierung für interne Services

Backend-zu-Backend-Kommunikation folgt anderen Anforderungen als Benutzer- oder Client-Authentifizierung. Hier kommen technische Mechanismen ohne interaktiven Authentifizierungsschritt zum Einsatz:

• mTLS, gegenseitige TLS-Authentifizierung; beide Seiten weisen sich mit Zertifikaten aus
• Signierte Service-Tokens, kurzlebige, kryptografisch signierte Tokens mit eng definierten Scopes; keine langlebigen Shared Secrets
• Secret Manager, Credentials, Zertifikate und Schlüssel werden nie in Konfigurationsdateien abgelegt, sondern über einen zentralen Secret Manager verwaltet und rotiert
• Private Netzwerkzonen, interne Services kommunizieren in abgeschirmten Netzwerksegmenten; keine direkte Erreichbarkeit aus dem öffentlichen Netz
• IP Allowlist, bei kritischen Systemen wird der Zugang zusätzlich auf bekannte IP-Bereiche eingeschränkt
• Token Rotation, auch Service-Tokens laufen kurz ab und werden regelmäßig erneuert