Entra ID SSO für Open WebUI, LiteLLM und n8n einrichten

Phillip Pham, Geschäftsführer bei Pexon Consulting | 11 Min. Lesezeit | 04.08.2026

TL;DR

Entra ID SSO für Open WebUI, LiteLLM und n8n bedeutet: eine Identität, ein Login, ein Offboarding für Ihren gesamten KI-Stack. Open WebUI und LiteLLM binden Sie über OAuth/OIDC an, n8n über SAML oder OIDC (ab Business-Plan). Diese Anleitung zeigt alle drei Schritt für Schritt, mit Redirect-URIs, Umgebungsvariablen und den häufigsten Entra-Fehlermeldungen.

Warum SSO für alle drei Tools, nicht nur für eins

Wer eine eigene KI-Plattform betreibt, hat selten nur ein Tool. Typisch ist der Dreiklang: Open WebUI als Chat-Frontend, LiteLLM als Gateway davor und n8n für Automatisierung dahinter. Drei Tools, und wenn jedes seinen eigenen Login hat, ist das ein Compliance-Problem, kein Komfortproblem.

Der Grund ist das Offboarding. Verlässt ein Mitarbeiter das Unternehmen, muss der Zugang zu allen drei Diensten verschwinden, nicht nur zu einem. Mit lokalen Logins pflegen Sie drei Benutzerlisten und vergessen garantiert eine. Mit Entra ID als zentralem Identity Provider deaktivieren Sie das Konto einmal, und alle drei Tools sind sofort dicht.

Ein zweiter Punkt: Ohne SSO nutzen Ihre Leute lokale Passwörter, oft schwache, oft wiederverwendete. Mit Entra ID greifen Ihre bestehenden Richtlinien, MFA und Conditional Access automatisch. Genau deshalb ist SSO die Grundlage jeder KI-Governance, nicht ein optionales Extra.

Was Sie für dieses Tutorial brauchen

• Ein Microsoft-Entra-ID-Tenant mit Rechten, App-Registrierungen und Enterprise-Applications anzulegen (Rolle Application Administrator oder höher).
• Open WebUI (Docker 0.6+) und LiteLLM Proxy, jeweils hinter einem Reverse Proxy mit gültigem SSL-Zertifikat.
• n8n in der Version, die SSO unterstützt, und ein Business- oder Enterprise-Plan: SAML und OIDC sind bei n8n kostenpflichtige Features, das ist der wichtigste Kostenpunkt dieser Anleitung.
• Für jedes Tool eine feste, per HTTPS erreichbare Domain (in den Beispielen ai.ihrefirma.de, gateway.ihrefirma.de, n8n.ihrefirma.de).

Ein Praxishinweis vorab: Wir haben diesen Stack bei einem Mittelständler mit rund 250 Mitarbeitern aufgesetzt. Der teuerste Fehler war ein Client-Secret mit sechs Monaten Laufzeit, das an einem Montagmorgen ablief und die halbe Belegschaft aussperrte. Dazu unten mehr.

Das Grundprinzip: getrennte Registrierungen statt einer Sammel-App

Die erste Designentscheidung: eine gemeinsame App-Registrierung für alles oder eine pro Tool? Unsere klare Empfehlung: pro Tool eine eigene Registrierung. Getrennte Client-Secrets, getrennte Berechtigungen, getrennte Rotation. Wird ein Tool kompromittiert oder läuft ein Secret ab, sind die anderen zwei nicht betroffen.

Konkret legen Sie an: zwei App-Registrierungen (OAuth/OIDC) für Open WebUI und LiteLLM, eine Enterprise-Application (SAML) oder App-Registrierung (OIDC) für n8n. Die Redirect-URIs unterscheiden sich pro Tool:

Schritt 1: App-Registrierungen in Entra ID anlegen

Öffnen Sie das Azure Portal, dann Microsoft Entra ID, dann App-Registrierungen, dann Neue Registrierung. Legen Sie zuerst die Registrierung für Open WebUI an.

Aus jeder Registrierung brauchen Sie drei Werte, die Sie sich notieren:

1. Anwendungs-ID (Client ID)
2. Verzeichnis-ID (Tenant ID)
3. Client Secret, das Sie unter „Zertifikate und Geheimnisse“ erzeugen

Beim Secret gilt: Setzen Sie die maximale Laufzeit (24 Monate) und tragen Sie das Ablaufdatum sofort in einen Kalender mit Erinnerung ein. Genau hier lag der eingangs erwähnte Montagmorgen-Ausfall.

Tragen Sie unter „Authentifizierung“ die Redirect-URI aus der Tabelle oben ein, exakt inklusive https:// und Pfad. Für Open WebUI und LiteLLM ergänzen Sie unter „API-Berechtigungen“ die delegierten Microsoft-Graph-Berechtigungen openid, email, profile und offline_access.

Schritt 2: Open WebUI mit Entra ID verbinden

Open WebUI (rund 131.000 GitHub-Stars, Stand August 2026) bringt Microsoft-OAuth nativ mit. Sie konfigurieren es über Umgebungsvariablen in der docker-compose.yml:

environment:
  - MICROSOFT_CLIENT_ID=<Client-ID aus Registrierung 1>
  - MICROSOFT_CLIENT_SECRET=<Client-Secret>
  - MICROSOFT_CLIENT_TENANT_ID=<Tenant-ID>
  - MICROSOFT_OAUTH_SCOPE=openid email profile offline_access
  - MICROSOFT_REDIRECT_URI=https://ai.ihrefirma.de/oauth/microsoft/callback
  - ENABLE_OAUTH_SIGNUP=true    # neue Nutzer per SSO automatisch anlegen
  - ENABLE_LOGIN_FORM=false     # lokales Login-Formular ausblenden
  - ENABLE_SIGNUP=false         # lokale Registrierung sperren

Die letzten drei Zeilen sind sicherheitskritisch: ENABLE_LOGIN_FORM=false und ENABLE_SIGNUP=false verhindern, dass jemand am SSO vorbei ein lokales Konto anlegt. Ohne sie ist die ganze SSO-Einrichtung ein Sicherheitstheater. Wie sich Open WebUI darüber hinaus produktiv absichern lässt, steht ausführlich in unserer Anleitung zu Open WebUI mit Entra ID.

Schritt 3: LiteLLM mit Entra ID verbinden

Beim LiteLLM-Gateway (rund 53.000 GitHub-Stars, Stand August 2026) sichern Sie die Admin-UI über SSO. Die Redirect-URI in der zweiten App-Registrierung lautet /sso/callback. Die Konfiguration läuft ebenfalls über Umgebungsvariablen:

# LiteLLM Proxy: SSO für die Admin-UI über Microsoft Entra ID
export MICROSOFT_CLIENT_ID="<Client-ID aus Registrierung 2>"
export MICROSOFT_CLIENT_SECRET="<Client-Secret>"
export MICROSOFT_TENANT="<Tenant-ID>"
export PROXY_BASE_URL="https://gateway.ihrefirma.de"
# Redirect-URI in Entra: https://gateway.ihrefirma.de/sso/callback

Ein sehr nützliches Detail: LiteLLM hat eine Debug-Route. Tragen Sie https://gateway.ihrefirma.de/sso/debug/callback als zusätzliche Redirect-URI ein und rufen Sie https://gateway.ihrefirma.de/sso/debug/login auf. Der Login zeigt Ihnen dann exakt, welche Attribute Entra zurückliefert, das spart bei fehlenden Claims viel Rätselraten.

Für die Rollenvergabe nutzen Sie App-Roles in der App-Registrierung: LiteLLM liest die Rollen aus dem JWT und weist sie automatisch zu, statt dass jeder eingeloggte Nutzer Admin wird. Die Basiskonfiguration des Gateways selbst behandelt unsere LiteLLM-Enterprise-Anleitung im Detail.

Schritt 4: n8n mit Entra ID verbinden

n8n ist der Sonderfall, und zwar aus einem Grund: SSO über SAML oder OIDC ist bei n8n ein Feature der Business- und Enterprise-Pläne, nicht der Community Edition. Rechnen Sie das ein, bevor Sie loslegen.

Der Ablauf unterscheidet sich von den ersten beiden Tools. Statt Werte in Entra einzutippen und dann ins Tool zu übertragen, generiert n8n die benötigten URLs selbst: Unter Settings > SSO finden Sie als Instance Owner die Redirect-URL (ACS) und die Entity ID. Diese tragen Sie in eine Enterprise-Application in Entra ein (für SAML) beziehungsweise in eine App-Registrierung (für OIDC). Danach kopieren Sie die IdP-Metadaten von Entra zurück in die n8n-SSO-Einstellungen.

Ein Stolperstein aus der Praxis: Wenn Sie Rollen über Azure-AD-Gruppen zuweisen, sendet die SAML-Assertion oft nur die erste passende Gruppe. Nutzen Sie stattdessen App-Roles in der App-Registrierung, dann kommen alle Rollen zuverlässig an. Halten Sie sich für die genauen Feldnamen an die offizielle n8n-Azure-AD-Dokumentation, da sich diese je Version unterscheiden.

Troubleshooting: die häufigsten Entra-Fehlermeldungen

Diese vier Fehler decken die große Mehrheit der gescheiterten Logins ab.

• AADSTS50011 (Redirect URI stimmt nicht überein): Die in Entra eingetragene URI weicht von der tatsächlichen ab, oft durch fehlendes https://, einen Tippfehler im Pfad oder einen Slash am Ende. Vergleichen Sie zeichengenau.
• AADSTS9002325 (Proof Key for Code Exchange fehlt): Die App-Registrierung ist als falscher Plattformtyp angelegt. Prüfen Sie, ob „Web“ statt „Single-Page Application“ gewählt ist.
• Kein E-Mail-Claim: Das Tool bekommt keine E-Mail-Adresse zurück. Ergänzen Sie den Scope email und, falls nötig, die optionalen Claims in der App-Registrierung.
• n8n zeigt nur ein Projekt trotz mehrerer Gruppen: Das ist das oben genannte Gruppen-Claim-Limit. Wechseln Sie auf App-Roles.

Sicherheits-Checkliste für den Produktionsbetrieb

Gehen Sie diese Liste durch, bevor Sie die drei Tools für alle freischalten.

1. Lokale Registrierung und lokales Login-Formular in Open WebUI deaktiviert (ENABLE_SIGNUP=false, ENABLE_LOGIN_FORM=false).
2. Client-Secret-Ablaufdaten aller Registrierungen im Kalender mit Vorlauf-Erinnerung.
3. Conditional-Access-Policy in Entra für alle drei Anwendungen (MFA, Gerätekonformität).
4. Rollen über App-Roles statt „jeder ist Admin“, in allen drei Tools.
5. Automatisches Deprovisioning per SCIM, damit gesperrte Konten wirklich überall verschwinden.
6. Secrets im Key Vault statt im Klartext in docker-compose.yml.
7. Ein Break-Glass-Administratorzugang, der auch bei einem Entra-Ausfall funktioniert.

Häufig gestellte Fragen

Kann ich eine einzige App-Registrierung für alle drei Tools nutzen?

Technisch ja, empfehlenswert nein. Getrennte Registrierungen bedeuten getrennte Secrets, Berechtigungen und Rotationszyklen. Fällt ein Secret aus oder wird ein Tool kompromittiert, bleiben die anderen zwei funktionsfähig. Der geringe Mehraufwand beim Anlegen zahlt sich im Betrieb aus.

Braucht n8n wirklich einen kostenpflichtigen Plan für SSO?

Ja. SAML- und OIDC-basiertes SSO ist bei n8n den Business- und Enterprise-Plänen vorbehalten, die Community Edition kann es nicht. Das ist der wesentliche Kostenpunkt, wenn Sie n8n in den SSO-Verbund aufnehmen wollen. Open WebUI und LiteLLM bringen SSO dagegen ohne zusätzliche Lizenz mit.

Wie funktioniert das Offboarding über alle drei Tools?

Sie deaktivieren das Konto in Entra ID, und beim nächsten Token-Refresh verlieren alle drei Tools den Zugang. Für sofortiges und lückenloses Deprovisioning ergänzen Sie SCIM, das gesperrte oder gelöschte Nutzer aktiv an die Tools meldet, statt auf den nächsten Login-Versuch zu warten.

Warum bekomme ich nach dem Login den Fehler AADSTS50011?

Die in Entra hinterlegte Redirect-URI stimmt nicht exakt mit der tatsächlichen überein. Prüfen Sie Protokoll (https://), Domain, Pfad und einen möglichen Slash am Ende zeichengenau. Das ist der mit Abstand häufigste Fehler bei der Ersteinrichtung.

Kann ich Rollen aus Entra automatisch in die Tools übernehmen?

Ja, über App-Roles in der App-Registrierung. LiteLLM liest sie aus dem JWT, n8n über die SAML-Assertion. Verlassen Sie sich nicht auf Gruppen-Claims, weil dabei oft nur die erste Gruppe übertragen wird und Nutzer dann zu wenige Rechte bekommen.

Nächster Schritt

Die drei Tools einzeln per SSO anzubinden, ist der überschaubare Teil. Der Aufwand steckt im sicheren Dauerbetrieb: SCIM, Conditional Access, Rollenmodell und Secret-Rotation über den gesamten Stack. Wenn Sie das sauber aufsetzen wollen, sprechen wir darüber.

Verwandte Themen