Federated Authentication Support
Open WebUI supports several forms of federated authentication:
- OAuth2
- Microsoft
- OIDC
- Trusted Header
OAuth
There are several global configuration options for OAuth:
ENABLE_OAUTH_SIGNUP
- iftrue
, allows accounts to be created when logging in with OAuth. Distinct fromENABLE_SIGNUP
.OAUTH_MERGE_ACCOUNTS_BY_EMAIL
- allows logging into an account that matches the email address provided by the OAuth provider.- This is considered insecure as not all OAuth providers verify email addresses, and may allow accounts to be hijacked.
Google
To configure a Google OAuth client, please refer to Google's documentation on how to create a Google OAuth client for a web application.
The allowed redirect URI should include <open-webui>/oauth/google/callback
.
The following environment variables are required:
GOOGLE_CLIENT_ID
- Google OAuth client IDGOOGLE_CLIENT_SECRET
- Google OAuth client secret
Microsoft
To configure a Microsoft OAuth client, please refer to Microsoft's documentation on how to create a Microsoft OAuth client for a web application.
The allowed redirect URI should include <open-webui>/oauth/microsoft/callback
.
Support for Microsoft OAuth is currently limited to a single tenant, that is a single Entra organization or personal Microsoft accounts.
The following environment variables are required:
MICROSOFT_CLIENT_ID
- Microsoft OAuth client IDMICROSOFT_CLIENT_SECRET
- Microsoft OAuth client secretMICROSOFT_CLIENT_TENANT_ID
- Microsoft tenant ID - use9188040d-6c67-4c5b-b112-36a304b66dad
for personal accounts
OIDC
Any authentication provider that supports OIDC can be configured.
The email
claim is required.
name
and picture
claims are used if available.
The allowed redirect URI should include <open-webui>/oauth/oidc/callback
.
The following environment variables are used:
OAUTH_CLIENT_ID
- OIDC client IDOAUTH_CLIENT_SECRET
- OIDC client secretOPENID_PROVIDER_URL
- OIDC well known URL, for examplehttps://accounts.google.com/.well-known/openid-configuration
OAUTH_PROVIDER_NAME
- Name of the provider to show on the UI, defaults to SSOOAUTH_SCOPES
- Scopes to request. Defaults toopenid email profile
Trusted Header
Open WebUI is able to delegate authentication to an authenticating reverse proxy that passes in the user's details in HTTP headers. There are several example configurations that are provided in this page.
Incorrect configuration can allow users to authenticate as any user on your Open WebUI instance.
Make sure to allow only the authenticating proxy access to Open WebUI, such as setting HOST=127.0.0.1
to only listen on the loopback interface.
Generic Configuration
When the WEBUI_AUTH_TRUSTED_EMAIL_HEADER
environment variable is set, Open WebUI will use the value of the header specified as the email address of the user, handling automatic registration and login.
For example, setting WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-User-Email
and passing a HTTP header of X-User-Email: example@example.com
would authenticate the request with the email example@example.com
.
Optionally, you can also define the WEBUI_AUTH_TRUSTED_NAME_HEADER
to determine the name of any user being created using trusted headers. This has no effect if the user already exists.
Tailscale Serve
Tailscale Serve allows you to share a service within your tailnet, and Tailscale will set the header Tailscale-User-Login
with the email address of the requester.
Below is an example serve config with a corresponding Docker Compose file that starts a Tailscale sidecar, exposing Open WebUI to the tailnet with the tag open-webui
and hostname open-webui
, and can be reachable at https://open-webui.TAILNET_NAME.ts.net
.
You will need to create an OAuth client with device write permission to pass into the Tailscale container as TS_AUTHKEY
.
{
"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: {}
If you run Tailscale in the same network context as Open WebUI, then by default users will be able to directly reach out to Open WebUI without going through the Serve proxy. You will need use Tailscale's ACLs to restrict access to only port 443.
Cloudflare Tunnel with Cloudflare Access
Cloudflare Tunnel can be used with Cloudflare Access to protect Open WebUI with SSO.
This is barely documented by Cloudflare, but Cf-Access-Authenticated-User-Email
is set with the email address of the authenticated user.
Below is an example Docker Compose file that sets up a Cloudflare sidecar.
Configuration is done via the dashboard.
From the dashboard, get a tunnel token, set the tunnel backend to http://open-webui:8080
, and ensure that "Protect with Access" is checked and configured.
---
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 is an authenticating reverse proxy that implements social OAuth providers and OIDC support.
Given the large number of potential configurations, below is an example of a potential setup with Google OAuth.
Please refer to oauth2-proxy
's documentation for detailed setup and any potential security gotchas.
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
Authelia
Authelia can be configured to return a header for use with trusted header authentication. Documentation is available here.
No example configs are provided due to the complexity of deploying Authelia.
Authentik
Authentik can be configured to return a header for use with trusted header authentication. Documentation is available here.
No example configs are provided due to the complexity of deploying Authentik.