Zum Hauptinhalt springen

Föderierte Authentifizierungsunterstützung

Open WebUI unterstützt verschiedene Formen der föderierten Authentifizierung

  1. OAuth2
    1. Google
    2. Microsoft
    3. Github
    4. OIDC
  2. Vertrauenswürdiger Header
Info

Weitere Informationen zu allen Umgebungsvariablen finden Sie auf der Dokumentationsseite für Umgebungsvariablen. Es wird dringend empfohlen, die Seite mit den Umgebungsvariablen zu überprüfen, um weitere Details darüber zu erhalten, wie die Variable gesetzt wird und welche Werte erwartet werden.

Gefahr

Derzeit kann nur ein OAUTH-Anbieter gleichzeitig konfiguriert werden. Sie können nicht Microsoft und Google als Anbieter gleichzeitig haben.

OAuth​

Es gibt mehrere globale Konfigurationsoptionen für OAuth im Allgemeinen

  1. ENABLE_OAUTH_SIGNUP - Wenn true, werden Konten beim Einloggen mit OAuth erstellt. Unterscheidet sich von ENABLE_SIGNUP.
  2. OAUTH_MERGE_ACCOUNTS_BY_EMAIL - Ermöglicht das Einloggen in ein Konto, das der vom OAuth-Anbieter bereitgestellten E-Mail-Adresse entspricht.
    • Dies gilt als unsicher, da nicht alle OAuth-Anbieter E-Mail-Adressen verifizieren und dies zur Übernahme von Konten führen kann.
  3. OAUTH_UPDATE_PICTURE_ON_LOGIN - Wenn true, werden Benutzerprofile mit OAuth-Bildern beim Einloggen aktualisiert.
    • Wenn der OAuth-Bild-Claim durch Setzen von OAUTH_PICTURE_CLAIM auf einen leeren String deaktiviert wird, wird diese Konfiguration ignoriert.
  4. OAUTH_PICTURE_CLAIM - Kann verwendet werden, um die Speicherung von Profilbildern anzupassen oder zu deaktivieren. Der Standardwert picture funktioniert für die meisten Anbieter. Wenn er auf einen leeren String gesetzt wird, erhalten alle Benutzer das Standardprofilbild einer Person.
  5. WEBUI_AUTH_SIGNOUT_REDIRECT_URI - Kann optional gesetzt werden, um den Benutzer nach dem Ausloggen an eine bestimmte URI weiterzuleiten.

Google​

Für die Konfiguration eines Google OAuth-Clients beachten Sie bitte die Google-Dokumentation zur Erstellung eines Google OAuth-Clients für eine Webanwendung. Die erlaubte Weiterleitungs-URI sollte <open-webui>/oauth/google/callback enthalten.

Die folgenden Umgebungsvariablen sind erforderlich

  1. GOOGLE_CLIENT_ID - Google OAuth Client ID
  2. GOOGLE_CLIENT_SECRET - Google OAuth Client Secret
  3. OPENID_PROVIDER_URL - Muss für die korrekte Funktion des Logouts gesetzt sein.

Microsoft​

Für die Konfiguration eines Microsoft OAuth-Clients beachten Sie bitte die Microsoft-Dokumentation zur Erstellung eines Microsoft OAuth-Clients für eine Webanwendung. Die erlaubte Weiterleitungs-URI sollte <open-webui>/oauth/microsoft/callback enthalten. Dieser Wert sollte für die Umgebungsvariable MICROSOFT_REDIRECT_URI verwendet werden.

Die Unterstützung für Microsoft OAuth ist derzeit auf einen einzelnen Mandanten beschränkt, d.h. auf eine einzelne Entra-Organisation oder persönliche Microsoft-Konten.

Die folgenden Umgebungsvariablen sind erforderlich

  1. MICROSOFT_CLIENT_ID - Microsoft OAuth Client ID
  2. MICROSOFT_CLIENT_SECRET - Microsoft OAuth Client Secret
  3. MICROSOFT_CLIENT_TENANT_ID - Microsoft Tenant ID - verwenden Sie 9188040d-6c67-4c5b-b112-36a304b66dad für persönliche Konten
  4. MICROSOFT_REDIRECT_URI - Die Weiterleitungs-URI, die in Ihrer Microsoft OAuth-Anwendung konfiguriert ist. Dies muss auf <open-webui>/oauth/microsoft/callback gesetzt werden.
  5. OPENID_PROVIDER_URL - Muss für die korrekte Funktion des Logouts gesetzt sein.

Github​

Für die Konfiguration eines Github OAuth-Clients beachten Sie bitte die Github-Dokumentation zur Erstellung einer OAuth App oder Github App für eine Webanwendung. Die erlaubte Weiterleitungs-URI sollte <open-webui>/oauth/github/callback enthalten.

Die folgenden Umgebungsvariablen sind erforderlich

  1. GITHUB_CLIENT_ID - Github OAuth App Client ID
  2. GITHUB_CLIENT_SECRET - Github OAuth App Client Secret
  3. OPENID_PROVIDER_URL - Muss für die korrekte Funktion des Logouts gesetzt sein.

OIDC​

Jeder Authentifizierungsanbieter, der OIDC unterstützt, kann konfiguriert werden. Der email-Claim ist erforderlich. name- und picture-Claims werden verwendet, falls verfügbar. Die erlaubte Weiterleitungs-URI sollte <open-webui>/oauth/oidc/callback enthalten.

Die folgenden Umgebungsvariablen werden verwendet

  1. OAUTH_CLIENT_ID - OIDC Client ID
  2. OAUTH_CLIENT_SECRET - OIDC Client Secret
  3. OPENID_PROVIDER_URL - OIDC Well-known URL, z.B. https://#/.well-known/openid-configuration
  4. OAUTH_PROVIDER_NAME - Name des Anbieters, der in der UI angezeigt wird, Standard ist SSO
  5. OAUTH_SCOPES - Angeforderte Scopes. Standard ist openid email profile
  6. OPENID_REDIRECT_URI - Die Weiterleitungs-URI, die in Ihrer OIDC-Anwendung konfiguriert ist. Dies muss auf <open-webui>/oauth/oidc/callback gesetzt werden.

OAuth Rollenverwaltung​

Jeder OAuth-Anbieter, der so konfiguriert werden kann, dass er Rollen im Zugriffstoken zurückgibt, kann zur Verwaltung von Rollen in Open WebUI verwendet werden. Um diese Funktion zu nutzen, setzen Sie ENABLE_OAUTH_ROLE_MANAGEMENT auf true. Sie können die folgenden Umgebungsvariablen konfigurieren, um sie an die vom OAuth-Anbieter zurückgegebenen Rollen anzupassen

  1. OAUTH_ROLES_CLAIM - Der Claim, der die Rollen enthält. Standard ist roles. Kann auch verschachtelt sein, z.B. user.roles.
  2. OAUTH_ALLOWED_ROLES - Eine kommaseparierte Liste von Rollen, die zum Einloggen berechtigt sind (erhalten die Open WebUI Rolle user).
  3. OAUTH_ADMIN_ROLES - Eine kommaseparierte Liste von Rollen, die sich als Administrator einloggen dürfen (erhalten die Open WebUI Rolle admin).
Info

Wenn Sie die Rolle eines eingeloggten Benutzers ändern, muss dieser sich ab- und wieder anmelden, um die neue Rolle zu erhalten.

OAuth Gruppenverwaltung​

Jeder OAuth-Anbieter, der so konfiguriert werden kann, dass er Gruppen im Zugriffstoken zurückgibt, kann zur Verwaltung von Benutzergruppen in Open WebUI beim Login des Benutzers verwendet werden. Um diese Synchronisierung zu aktivieren, setzen Sie ENABLE_OAUTH_GROUP_MANAGEMENT auf true.

Sie können die folgenden Umgebungsvariablen konfigurieren

  1. OAUTH_GROUP_CLAIM - Der Claim im ID/Zugriffstoken, der die Gruppenzugehörigkeiten des Benutzers enthält. Standard ist groups. Kann auch verschachtelt sein, z.B. user.memberOf. Erforderlich, wenn ENABLE_OAUTH_GROUP_MANAGEMENT auf true gesetzt ist.
  2. ENABLE_OAUTH_GROUP_CREATION - Wenn true (und ENABLE_OAUTH_GROUP_MANAGEMENT ebenfalls true ist), wird Open WebUI eine Just-in-Time (JIT) Gruppenerstellung durchführen. Das bedeutet, dass Gruppen automatisch während des OAuth-Logins erstellt werden, wenn sie in den OAuth-Claims des Benutzers vorhanden sind, aber noch nicht im System existieren. Standard ist false. Wenn false, werden nur Mitgliedschaften in *bestehenden* Open WebUI-Gruppen verwaltet.
Strikte Gruppensynchronisierung

Wenn ENABLE_OAUTH_GROUP_MANAGEMENT auf true gesetzt ist, werden die Gruppenzugehörigkeiten eines Benutzers in Open WebUI bei jedem Login strikt mit den Gruppen synchronisiert, die in seinen OAuth-Claims empfangen werden.

  • Benutzer werden zu Open WebUI-Gruppen hinzugefügt, die mit ihren OAuth-Claims übereinstimmen.
  • Benutzer werden aus allen Open WebUI-Gruppen (einschließlich manuell erstellter oder zugewiesener Gruppen in Open WebUI) entfernt, wenn diese Gruppen während der aktuellen Login-Sitzung nicht in ihren OAuth-Claims vorhanden sind.

Stellen Sie sicher, dass alle erforderlichen Gruppen in Ihrem OAuth-Anbieter korrekt konfiguriert und im Gruppen-Claim (OAUTH_GROUP_CLAIM) enthalten sind.

Admin-Benutzer

Die Gruppenzugehörigkeiten von Admin-Benutzern werden über die OAuth-Gruppenverwaltung nicht automatisch aktualisiert.

Login für Updates erforderlich

Wenn sich die Gruppen eines Benutzers im OAuth-Anbieter ändern, muss sich dieser aus Open WebUI ab- und wieder anmelden, damit die Änderungen übernommen werden.

Vertrauenswürdiger Header​

Open WebUI kann die Authentifizierung an einen authentifizierenden Reverse-Proxy delegieren, der die Benutzerdetails in HTTP-Headern übergibt. Auf dieser Seite finden Sie verschiedene Beispielkonfigurationen.

Gefahr

Eine fehlerhafte Konfiguration kann dazu führen, dass sich Benutzer als beliebige Benutzer auf Ihrer Open WebUI-Instanz authentifizieren. Stellen Sie sicher, dass nur der authentifizierende Proxy Zugriff auf Open WebUI erhält, z.B. durch Setzen von HOST=127.0.0.1, um nur auf der Loopback-Schnittstelle zu lauschen.

Generische Konfiguration​

Wenn die Umgebungsvariable WEBUI_AUTH_TRUSTED_EMAIL_HEADER gesetzt ist, verwendet Open WebUI den Wert des angegebenen Headers als E-Mail-Adresse des Benutzers und übernimmt die automatische Registrierung und den Login.

Beispielsweise würde das Setzen von WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-User-Email und das Übergeben eines HTTP-Headers von X-User-Email: example@example.com die Anfrage mit der E-Mail-Adresse example@example.com authentifizieren.

Optional können Sie auch WEBUI_AUTH_TRUSTED_NAME_HEADER definieren, um den Namen eines Benutzers zu bestimmen, der über vertrauenswürdige Header erstellt wird. Dies hat keine Auswirkung, wenn der Benutzer bereits existiert. Wenn WEBUI_AUTH_TRUSTED_NAME_HEADER nicht gesetzt ist, wird die E-Mail-Adresse als Benutzername verwendet.

Gruppenverwaltung​

Sie können die Umgebungsvariable WEBUI_AUTH_TRUSTED_GROUPS_HEADER verwenden, um Benutzergruppen in Open WebUI zu synchronisieren. Setzen Sie diese Variable auf den Namen des HTTP-Headers, der eine kommaseparierte Liste von Gruppennamen für den authentifizierten Benutzer enthält.

Wenn eine Anfrage über WEBUI_AUTH_TRUSTED_EMAIL_HEADER authentifiziert wird und der vertrauenswürdige Gruppen-Header gesetzt und vorhanden ist, aktualisiert Open WebUI die Gruppenzugehörigkeiten des Benutzers, um mit den im Header aufgeführten Gruppen übereinzustimmen.

  • Der Header-Wert muss eine kommaseparierte Liste von Gruppennamen sein (z.B. X-User-Groups: admins,editors,users).
  • Wenn der Header nicht vorhanden oder leer ist, werden die Gruppenzugehörigkeiten des Benutzers nicht aktualisiert.
  • Benutzer werden aus Gruppen, die nicht im Header vorhanden sind, abgemeldet.
  • Die Gruppenerstellung über vertrauenswürdige Header erfolgt nicht automatisch; nur vorhandene Gruppen in Open WebUI werden zugewiesen.

Tailscale Serve​

Tailscale Serve ermöglicht es Ihnen, einen Dienst innerhalb Ihres Tailnets zu teilen. Tailscale setzt dann den Header Tailscale-User-Login mit der E-Mail-Adresse des Anfragenden.

Unten sehen Sie ein Beispiel für eine Serve-Konfiguration mit einer entsprechenden Docker Compose-Datei, die einen Tailscale-Sidecar startet und Open WebUI für das Tailnet mit dem Tag open-webui und dem Hostnamen open-webui bereitstellt. Es ist erreichbar unter https://open-webui.TAILNET_NAME.ts.net. Sie müssen einen OAuth-Client mit Geräte-Schreibberechtigung erstellen, der als TS_AUTHKEY in den Tailscale-Container übergeben wird.

tailscale/serve.json
{
    "TCP": {
        "443": {
            "HTTPS": true
        }
    },
    "Web": {
        "${TS_CERT_DOMAIN}:443": {
            "Handlers": {
                "/": {
                    "Proxy": "http://open-webui:8080"
                }
            }
        }
    }
}

docker-compose.yaml
---
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    volumes:
      - open-webui:/app/backend/data
    environment:
      - HOST=127.0.0.1
      - WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Tailscale-User-Login
      - WEBUI_AUTH_TRUSTED_NAME_HEADER=Tailscale-User-Name
    restart: unless-stopped
  tailscale:
    image: tailscale/tailscale:latest
    environment:
      - TS_AUTH_ONCE=true
      - TS_AUTHKEY=${TS_AUTHKEY}
      - TS_EXTRA_ARGS=--advertise-tags=tag:open-webui
      - TS_SERVE_CONFIG=/config/serve.json
      - TS_STATE_DIR=/var/lib/tailscale
      - TS_HOSTNAME=open-webui
    volumes:
      - tailscale:/var/lib/tailscale
      - ./tailscale:/config
      - /dev/net/tun:/dev/net/tun
    cap_add:
      - net_admin
      - sys_module
    restart: unless-stopped

volumes:
  open-webui: {}
  tailscale: {}
Warnung

Wenn Sie Tailscale im selben Netzwerkkontext wie Open WebUI ausführen, können Benutzer standardmäßig direkt auf Open WebUI zugreifen, ohne den Serve-Proxy zu durchlaufen. Sie müssen Tailscale-ACLs verwenden, um den Zugriff auf Port 443 zu beschränken.

Cloudflare Tunnel mit Cloudflare Access​

Cloudflare Tunnel kann mit Cloudflare Access verwendet werden, um Open WebUI mit SSO zu schützen. Dies ist von Cloudflare kaum dokumentiert, aber Cf-Access-Authenticated-User-Email wird mit der E-Mail-Adresse des authentifizierten Benutzers gesetzt.

Unten finden Sie eine Beispiel-Docker Compose-Datei, die einen Cloudflare-Sidecar einrichtet. Die Konfiguration erfolgt über das Dashboard. Rufen Sie vom Dashboard ein Tunnel-Token ab, setzen Sie das Tunnel-Backend auf http://open-webui:8080 und stellen Sie sicher, dass "Protect with Access" aktiviert und konfiguriert ist.

docker-compose.yaml
---
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    volumes:
      - open-webui:/app/backend/data
    environment:
      - HOST=127.0.0.1
      - WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Cf-Access-Authenticated-User-Email
    restart: unless-stopped
  cloudflared:
    image: cloudflare/cloudflared:latest
    environment:
      - TUNNEL_TOKEN=${TUNNEL_TOKEN}
    command: tunnel run
    restart: unless-stopped

volumes:
  open-webui: {}

oauth2-proxy​

oauth2-proxy ist ein authentifizierender Reverse-Proxy, der soziale OAuth-Provider und OIDC-Unterstützung implementiert.

Angesichts der Vielzahl möglicher Konfigurationen finden Sie unten ein Beispiel für eine mögliche Einrichtung mit Google OAuth. Bitte konsultieren Sie die Dokumentation von oauth2-proxy für eine detaillierte Einrichtung und mögliche Sicherheitsprobleme.

docker-compose.yaml
services:
  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    volumes:
      - open-webui:/app/backend/data
    environment:
      - 'HOST=127.0.0.1'
      - 'WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-Forwarded-Email'
      - 'WEBUI_AUTH_TRUSTED_NAME_HEADER=X-Forwarded-User'
    restart: unless-stopped
  oauth2-proxy:
    image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0
    environment:
      OAUTH2_PROXY_HTTP_ADDRESS: 0.0.0.0:4180
      OAUTH2_PROXY_UPSTREAMS: http://open-webui:8080/
      OAUTH2_PROXY_PROVIDER: google
      OAUTH2_PROXY_CLIENT_ID: REPLACEME_OAUTH_CLIENT_ID
      OAUTH2_PROXY_CLIENT_SECRET: REPLACEME_OAUTH_CLIENT_ID
      OAUTH2_PROXY_EMAIL_DOMAINS: REPLACEME_ALLOWED_EMAIL_DOMAINS
      OAUTH2_PROXY_REDIRECT_URL: REPLACEME_OAUTH_CALLBACK_URL
      OAUTH2_PROXY_COOKIE_SECRET: REPLACEME_COOKIE_SECRET
      OAUTH2_PROXY_COOKIE_SECURE: "false"
    restart: unless-stopped
    ports:
      - 4180:4180/tcp

Authentik​

Für die Konfiguration eines Authentik OAuth-Clients beachten Sie bitte die Dokumentation zur Erstellung einer Anwendung und eines OAuth2/OpenID Providers. Die erlaubte Weiterleitungs-URI sollte <open-webui>/oauth/oidc/callback enthalten.

Bitte beachten Sie bei der Erstellung des Anbieters App-name, Client-ID und Client-Secret und verwenden Sie diese für die Open-WebUI-Umgebungsvariablen.

      - 'ENABLE_OAUTH_SIGNUP=true'
      - 'OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true'
      - 'OAUTH_PROVIDER_NAME=Authentik'
      - 'OPENID_PROVIDER_URL=https://<authentik-url>/application/o/<App-name>/.well-known/openid-configuration'
      - 'OAUTH_CLIENT_ID=<Client-ID>'
      - 'OAUTH_CLIENT_SECRET=<Client-Secret>'
      - 'OAUTH_SCOPES=openid email profile'
      - 'OPENID_REDIRECT_URI=https://<open-webui>/oauth/oidc/callback'

Authelia​

Authelia kann so konfiguriert werden, dass ein Header für die Authentifizierung über vertrauenswürdige Header zurückgegeben wird. Die Dokumentation ist hier verfügbar.

Aufgrund der Komplexität der Bereitstellung von Authelia werden keine Beispielkonfigurationen bereitgestellt.