Unterstützung für föderierte Authentifizierung
Open WebUI unterstützt mehrere Formen der föderierten Authentifizierung:
- OAuth2
- Microsoft
- Github
- OIDC
- Vertrauenswürdige Header
OAuth
Es gibt mehrere globale Konfigurationsoptionen für OAuth:
ENABLE_OAUTH_SIGNUP
- Wenntrue
, können Konten erstellt werden, wenn man sich mit OAuth anmeldet. Unterschiedlich zuENABLE_SIGNUP
.OAUTH_MERGE_ACCOUNTS_BY_EMAIL
- Ermöglicht die Anmeldung bei einem Konto, das der von dem OAuth-Anbieter bereitgestellten E-Mail-Adresse entspricht.- Dies gilt als unsicher, da nicht alle OAuth-Anbieter E-Mail-Adressen überprüfen, und es möglicherweise erlaubt, Konten zu kapern.
OAUTH_UPDATE_PICTURE_ON_LOGIN
- Wenntrue
, werden bei der Anmeldung die von OAuth bereitgestellten Profilbilder der Nutzer aktualisiert.- Wenn das OAuth-Bild-Attribut durch Festlegen von
OAUTH_PICTURE_CLAIM
auf einen leeren String deaktiviert wird, wird diese Konfiguration ignoriert.
- Wenn das OAuth-Bild-Attribut durch Festlegen von
OAUTH_PICTURE_CLAIM
- Kann genutzt werden, um die Speicherung von Profilbildern anzupassen oder zu deaktivieren. Der Standardwertpicture
funktioniert bei den meisten Anbietern; Wenn auf einen leeren String gesetzt, erhalten alle Nutzer das Standard-Profilbild einer Person.
Google
Um einen Google OAuth-Client zu konfigurieren, lesen Sie bitte Googles 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:
GOOGLE_CLIENT_ID
- Google OAuth Client-IDGOOGLE_CLIENT_SECRET
- Google OAuth Client-Secret
Microsoft
Um einen Microsoft OAuth-Client zu konfigurieren, lesen Sie bitte Microsofts Dokumentation zur Erstellung eines Microsoft OAuth-Clients für eine Webanwendung.
Die erlaubte Weiterleitungs-URI sollte <open-webui>/oauth/microsoft/callback
enthalten.
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:
MICROSOFT_CLIENT_ID
- Microsoft OAuth Client-IDMICROSOFT_CLIENT_SECRET
- Microsoft OAuth Client-SecretMICROSOFT_CLIENT_TENANT_ID
- Microsoft Mandanten-ID - Verwenden Sie9188040d-6c67-4c5b-b112-36a304b66dad
für persönliche Konten
Github
Um einen Github OAuth-Client zu konfigurieren, lesen Sie bitte Githubs 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:
GITHUB_CLIENT_ID
- Github OAuth-App Client-IDGITHUB_CLIENT_SECRET
- Github OAuth-App Client-Secret
OIDC
Jeder Authentifizierungsanbieter, der OIDC unterstützt, kann konfiguriert werden.
Das email
-Attribut ist erforderlich.
name
- und picture
-Attribute werden verwendet, wenn verfügbar.
Die erlaubte Weiterleitungs-URI sollte <open-webui>/oauth/oidc/callback
enthalten.
Die folgenden Umgebungsvariablen werden verwendet:
OAUTH_CLIENT_ID
- OIDC Client-IDOAUTH_CLIENT_SECRET
- OIDC Client-SecretOPENID_PROVIDER_URL
- OIDC Well-Known-URL, z.B.https://accounts.google.com/.well-known/openid-configuration
OAUTH_PROVIDER_NAME
- Name des Anbieters, der auf der Benutzeroberfläche angezeigt wird, Standardwert ist SSOOAUTH_SCOPES
- Anzufordernde Berechtigungen. Standard istopenid email profile
OAuth Rollenverwaltung
Jeder OAuth-Anbieter, der konfiguriert werden kann, um Rollen im Zugriffstoken zurückzugeben, kann zur Rollenverwaltung 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 die Rollen, die von den OAuth-Anbietern zurückgegeben werden, abzugleichen:
OAUTH_ROLES_CLAIM
- Das Attribut, das die Rollen enthält. Standardwert istroles
. Kann auch verschachtelt sein, z.B.user.roles
.OAUTH_ALLOWED_ROLES
- Eine durch Komma getrennte Liste von Rollen, die sich anmelden dürfen (erhält die Open-WebUI-Rolleuser
).OAUTH_ADMIN_ROLES
- Eine durch Komma getrennte Liste von Rollen, die sich als Admin anmelden dürfen (erhält die Open-WebUI-Rolleadmin
).
Wenn sich die Rolle eines angemeldeten Nutzers ändert, muss dieser sich ausloggen und erneut anmelden, um die neue Rolle zu erhalten.
OAuth Gruppenverwaltung
Jeder OAuth-Anbieter, der konfiguriert werden kann, um Gruppen im Zugriffstoken zurückzugeben, kann verwendet werden, um Nutzergruppen in Open WebUI bei der Anmeldung eines Nutzers zu verwalten.
Um diese Synchronisierung zu aktivieren, setzen Sie ENABLE_OAUTH_GROUP_MANAGEMENT
auf true
.
Sie können die folgenden Umgebungsvariablen konfigurieren:
OAUTH_GROUP_CLAIM
- Das Attribut im ID-/Zugriffstoken, das die Gruppenmitgliedschaften des Nutzers enthält. Standardwert istgroups
. Kann auch verschachtelt sein, z.B.user.memberOf
. Erforderlich, wennENABLE_OAUTH_GROUP_MANAGEMENT
wahr ist.ENABLE_OAUTH_GROUP_CREATION
- Wenn auftrue
gesetzt (undENABLE_OAUTH_GROUP_MANAGEMENT
ebenfalls auftrue
gesetzt ist), wird Open WebUI Just-in-Time (JIT) Gruppen-Erstellung durchführen. Das bedeutet, dass bei der OAuth-Anmeldung automatisch Gruppen erstellt werden, wenn diese in den OAuth-Ansprüchen des Benutzers vorhanden sind, aber noch nicht im System existieren. Standardmäßig auffalse
gesetzt. Wennfalse
, werden nur Mitgliedschaften in bereits bestehenden Open WebUI-Gruppen verwaltet.
Wenn ENABLE_OAUTH_GROUP_MANAGEMENT
auf true
gesetzt ist, werden die Gruppenmitgliedschaften eines Benutzers in Open WebUI strikt synchronisiert mit den Gruppen, die bei jeder Anmeldung in seinen OAuth-Ansprüchen angegeben sind.
- Benutzer werden hinzugefügt zu Open WebUI-Gruppen, die mit ihren OAuth-Ansprüchen übereinstimmen.
- Benutzer werden entfernt aus beliebigen Open WebUI-Gruppen (einschließlich solcher, die manuell in Open WebUI erstellt oder zugewiesen wurden), wenn diese Gruppen nicht in ihren OAuth-Ansprüchen für diese Anmeldesitzung vorhanden sind.
Stellen Sie sicher, dass alle benötigten Gruppen korrekt in Ihrem OAuth-Anbieter konfiguriert sind und im Gruppenanspruch (OAUTH_GROUP_CLAIM
) enthalten sind.
Die Gruppenmitgliedschaften von Admin-Benutzern werden nicht automatisch über das OAuth-Gruppenmanagement aktualisiert.
Wenn sich die Gruppen eines Benutzers im OAuth-Anbieter ändern, muss sich der Benutzer von Open WebUI abmelden und erneut anmelden, damit die Änderungen wirksam werden.
Vertrauenswürdiger Header
Open WebUI kann die Authentifizierung an einen authentifizierenden Reverse-Proxy delegieren, der die Details des Benutzers in HTTP-Headern übermittelt. Es gibt mehrere Beispielkonfigurationen, die auf dieser Seite bereitgestellt werden.
:::gefährlich
Eine fehlerhafte Konfiguration kann Benutzern ermöglichen, sich als jeder Benutzer auf Ihrer Open WebUI-Instanz zu authentifizieren.
Stellen Sie sicher, dass nur der authentifizierende Proxy Zugriff auf Open WebUI hat, z. B. indem Sie HOST=127.0.0.1
setzen, 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 führt automatische Registrierung und Anmeldung durch.
Beispielsweise würde die Einstellung von WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-User-Email
und das Übergeben eines HTTP-Headers X-User-Email: [email protected]
die Anfrage mit der E-Mail [email protected]
authentifizieren.
Optional können Sie auch WEBUI_AUTH_TRUSTED_NAME_HEADER
definieren, um den Namen eines Benutzers zu bestimmen, der mit vertrauenswürdigen Headern erstellt wird. Dies hat keine Wirkung, wenn der Benutzer bereits existiert.
Tailscale Serve
Tailscale Serve ermöglicht es, einen Dienst innerhalb Ihres Tailnets freizugeben, und Tailscale setzt den Header Tailscale-User-Login
mit der E-Mail-Adresse des Anfragenden.
Unten finden Sie eine Beispiel-Serve-Konfiguration mit einer entsprechenden Docker-Compose-Datei, die einen Tailscale-Sidecar startet, Open WebUI mit dem Tag open-webui
und Hostnamen open-webui
im Tailnet bereitstellt und unter https://open-webui.TAILNET_NAME.ts.net
erreichbar macht.
Sie müssen einen OAuth-Client mit Schreibberechtigung für Geräte erstellen, um ihn als TS_AUTHKEY
in den Tailscale-Container einzubringen.
{
"TCP": {
"443": {
"HTTPS": true
}
},
"Web": {
"${TS_CERT_DOMAIN}:443": {
"Handlers": {
"/": {
"Proxy": "http://open-webui:8080"
}
}
}
}
}
---
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: {}
Wenn Sie Tailscale im gleichen Netzwerk-Kontext wie Open WebUI ausführen, können Benutzer standardmäßig direkt auf Open WebUI zugreifen, ohne den Serve-Proxy zu durchlaufen. Sie müssen Tailscales ACLs verwenden, um den Zugriff nur 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.
Holen Sie sich ein Tunnel-Token aus dem Dashboard, setzen Sie das Tunnel-Backend auf http://open-webui:8080
und stellen Sie sicher, dass "Mit Access schützen" aktiviert und konfiguriert ist.
---
Dienste:
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 authenticating Reverse Proxy, der soziale OAuth-Anbieter und OIDC-Unterstützung implementiert.
Aufgrund 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 eventuelle Sicherheitsprobleme.
Dienste:
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
Um einen Authentik OAuth-Client zu konfigurieren, konsultieren Sie bitte die Dokumentation darüber, wie ein Anwendung und OAuth2/OpenID Provider
erstellt werden.
Die zugelassene Redirect-URI sollte <open-webui>/oauth/oidc/callback
enthalten.
Während der Erstellung des Providers beachten Sie bitte 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 Verwendung mit Trusted-Header-Authentifizierung zurückgegeben wird. Die Dokumentation ist hier verfügbar.
Es werden keine Beispielkonfigurationen bereitgestellt, da die Bereitstellung von Authelia komplex ist.