Is your feature request related to a problem? Please describe.
Add feature to enable account creation via OAuth/OIDC
Describe the solution you'd like
Integrating ollama-webui with auth providers such as Authentik, Keycloak, etc
Describe alternatives you've considered
N/A
Additional context
Being able to create a local account as an admin upon initialization should remain, but afterwards the admin account should be able to add the relevant information to change the default login page to redirect to a self-hosted OAuth/OIDC provider
Originally created by @Kryszn0 on GitHub (Jan 15, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/483
**Is your feature request related to a problem? Please describe.**
Add feature to enable account creation via OAuth/OIDC
**Describe the solution you'd like**
Integrating ollama-webui with auth providers such as Authentik, Keycloak, etc
**Describe alternatives you've considered**
N/A
**Additional context**
Being able to create a local account as an admin upon initialization should remain, but afterwards the admin account should be able to add the relevant information to change the default login page to redirect to a self-hosted OAuth/OIDC provider
From the ollama-webui side, you'd configure some envvar like OLLAMA_AUTH_TRUSTED_HEADER=X-Remote-User to enable this delegated auth mode. The Python backend would look for this header and automatically log in or create an account for the user given in the header value.
I wondering if this approach would cover your auth use cases as well? If so, I might take a stab at a PR implementation.
<!-- gh-comment-id:1913402273 -->
@josh commented on GitHub (Jan 28, 2024):
Ever since the new user accounts were rolled out, I've been wanting some kind of way to delegate auth as well.
In my specific case, my ollama-webui is behind a [Tailscale](https://tailscale.com) VPN. They have a pretty lightweight set of [trusted identity headers](https://tailscale.com/kb/1312/serve#identity-headers) when proxied to. It seems like a few other SSO providers like [Authelia can be configured to pass along trusted headers](https://caddyserver.com/docs/caddyfile/directives/forward_auth#examples).
From the ollama-webui side, you'd configure some envvar like `OLLAMA_AUTH_TRUSTED_HEADER=X-Remote-User` to enable this delegated auth mode. The Python backend would look for this header and automatically log in or create an account for the user given in the header value.
I wondering if this approach would cover your auth use cases as well? If so, I might take a stab at a PR implementation.
<!-- gh-comment-id:1936669906 -->
@explorigin commented on GitHub (Feb 9, 2024):
Just a heads up. I'm working on integrating https://fastapi-users.github.io/fastapi-users/latest/ into ollama-webui. That will give us OAUTH2 for these clients: https://frankie567.github.io/httpx-oauth/oauth2/#provided-clients. Give me a few weeks.
thanks @explorigin 🙇 it will be a killer feature in the open llm UI market.
I am keen to have this feature for demo in the coming weeks, if you don't mind, Could I know if there's any estimation for it available?
<!-- gh-comment-id:1963923616 -->
@elvis-cai commented on GitHub (Feb 26, 2024):
thanks @explorigin 🙇 it will be a killer feature in the open llm UI market.
I am keen to have this feature for demo in the coming weeks, if you don't mind, Could I know if there's any estimation for it available?
Sorry, no estimate. I started on it but work/life got crazy. If you need it for work then work on it. I've started with fastapi-users library but that has some considerations:
It uses different REST-API endpoints that are difficult to customize so changing some of these will require a bit of front-end work as well.
It uses a slightly different DB schema that will need reconciling
Open-WebUI uses Peewee. FastAPI-users has adapters for other ORMs but not Peewee. I haven't decided if I'm going to roll a convert to SQLAlchemy in this or write a Peewee adapter.
And that's all before getting to the Oauth configuration that needs to be exposed in a smart manner. So it's not a simple feature.
<!-- gh-comment-id:1964158623 -->
@explorigin commented on GitHub (Feb 26, 2024):
Sorry, no estimate. I started on it but work/life got crazy. If you need it for work then work on it. I've started with fastapi-users library but that has some considerations:
- It uses different REST-API endpoints that are difficult to customize so changing some of these will require a bit of front-end work as well.
- It uses a slightly different DB schema that will need reconciling
- Open-WebUI uses Peewee. FastAPI-users has adapters for other ORMs but not Peewee. I haven't decided if I'm going to roll a convert to SQLAlchemy in this or write a Peewee adapter.
And that's all before getting to the Oauth configuration that needs to be exposed in a smart manner. So it's not a simple feature.
I will be interested on testing this when it is available. It would be great to add an option to automatically verify users based on their domain.
Keep the good job guys!
<!-- gh-comment-id:1983650108 -->
@aitzubi commented on GitHub (Mar 7, 2024):
I will be interested on testing this when it is available. It would be great to add an option to automatically verify users based on their domain.
Keep the good job guys!
+1 for auth via Forwarded Headers, for many selfhosted setups OIDC/OAuth is pretty overkill. (Though still very useful for public instances)
<!-- gh-comment-id:1987255255 -->
@m00nwtchr commented on GitHub (Mar 10, 2024):
+1 for auth via Forwarded Headers, for many selfhosted setups OIDC/OAuth is pretty overkill. (Though still very useful for public instances)
Not quite what was asked for with OAuth/OIDC for the actual auth, but I've yolo'd in a patch for my own use case with trusted headers, https://github.com/open-webui/open-webui/compare/dev...cheahjs:open-webui-fork:feat/trusted-email-header Users will still have to enter their email addresses to sign up and sign in (I've implemented automatic registration and sign in for users that have been authed by the header), but I've tested it with WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Tailscale-User-Login for Tailscale Serve, and WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-WebAuth-User with gcp-iap-auth + Google Clouds's Identity Aware Proxy
<!-- gh-comment-id:2021531159 -->
@cheahjs commented on GitHub (Mar 26, 2024):
Not quite what was asked for with OAuth/OIDC for the actual auth, but I've yolo'd in a patch for my own use case with trusted headers, https://github.com/open-webui/open-webui/compare/dev...cheahjs:open-webui-fork:feat/trusted-email-header
~~Users will still have to enter their email addresses to sign up and sign in~~ (I've implemented automatic registration and sign in for users that have been authed by the header), but I've tested it with `WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Tailscale-User-Login` for [Tailscale Serve](https://tailscale.com/kb/1312/serve#identity-headers), and `WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-WebAuth-User` with [gcp-iap-auth](https://github.com/imkira/gcp-iap-auth) + Google Clouds's Identity Aware Proxy
Yep, I announced and then ghosted. Sorry. Going through a job change. Don't count on me for this.
<!-- gh-comment-id:2021563516 -->
@explorigin commented on GitHub (Mar 26, 2024):
Yep, I announced and then ghosted. Sorry. Going through a job change. Don't count on me for this.
Given the newly merged trusted email header feature, Open WebUI doesn't support federated auth by itself, but it can offload auth to a authenticating proxy. Some example compose stacks (these are not exactly production ready, remember to harden where necessary with your own secrets):
Tailscale Serve
Starts Tailscale as a sidecar, and exposes Open WebUI via Tailscale Serve. Authorization should be handled using your tailnet's ACL rules.
oauth2-proxy supports multiple OAuth providers and OIDC (list of providers). You will need to configure the providers and how to handle authorization yourself. I have not tested this.
upstreams:- id:open-webuipath:/uri:http://open-webui:8080injectRequestHeaders:- name:X-Forwarded-Emailvalues:- claim:emailproviders:# Provide a list of providers to use for authentication# https://oauth2-proxy.github.io/oauth2-proxy/configuration/providers/
For anyone running Open WebUI inside of GCP, I've deployed Identity Aware Proxy with gcp-iap-auth as a reverse proxy to extract the email from the JWT.
<!-- gh-comment-id:2035267852 -->
@cheahjs commented on GitHub (Apr 3, 2024):
Given the newly merged trusted email header feature, Open WebUI doesn't support federated auth by itself, but it can offload auth to a authenticating proxy. Some example compose stacks (these are not exactly production ready, remember to harden where necessary with your own secrets):
<details>
<summary>Tailscale Serve</summary>
Starts Tailscale as a sidecar, and exposes Open WebUI via [Tailscale Serve](https://tailscale.com/kb/1242/tailscale-serve). Authorization should be handled using your tailnet's ACL rules.
<details>
<summary>docker-compose.yaml</summary>
```yaml
version: '3.8'
services:
ollama:
volumes:
- ollama:/root/.ollama
container_name: ollama
pull_policy: always
tty: true
restart: unless-stopped
image: ollama/ollama:latest
open-webui:
build:
context: .
args:
OLLAMA_BASE_URL: '/ollama'
dockerfile: Dockerfile
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
volumes:
- open-webui:/app/backend/data
depends_on:
- ollama
environment:
- 'OLLAMA_BASE_URL=http://ollama:11434'
- 'WEBUI_SECRET_KEY='
- 'WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Tailscale-User-Login'
extra_hosts:
- host.docker.internal:host-gateway
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-serve.json:/config/serve.json
- /dev/net/tun:/dev/net/tun
cap_add:
- net_admin
- sys_module
restart: unless-stopped
volumes:
ollama: {}
open-webui: {}
tailscale: {}
```
</details>
<details>
<summary>tailscale-serve.json</summary>
```json
{
"TCP": {
"443": {
"HTTPS": true
}
},
"Web": {
"${TS_CERT_DOMAIN}:443": {
"Handlers": {
"/": {
"Proxy": "http://open-webui:8080"
}
}
}
}
}
```
</details>
</details>
<details>
<summary>oauth2-proxy</summary>
`oauth2-proxy` supports multiple OAuth providers and OIDC ([list of providers](https://oauth2-proxy.github.io/oauth2-proxy/configuration/providers/)). You will need to configure the providers and how to handle authorization yourself. I have not tested this.
<details>
<summary>docker-compose.yaml</summary>
```yaml
version: '3.8'
services:
ollama:
volumes:
- ollama:/root/.ollama
container_name: ollama
pull_policy: always
tty: true
restart: unless-stopped
image: ollama/ollama:latest
open-webui:
build:
context: .
args:
OLLAMA_BASE_URL: '/ollama'
dockerfile: Dockerfile
image: ghcr.io/open-webui/open-webui:main
container_name: open-webui
volumes:
- open-webui:/app/backend/data
depends_on:
- ollama
environment:
- 'OLLAMA_BASE_URL=http://ollama:11434'
- 'WEBUI_SECRET_KEY='
- 'WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-Forwarded-Email'
extra_hosts:
- host.docker.internal:host-gateway
restart: unless-stopped
oauth2-proxy:
image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0
command: --config /oauth2-proxy.cfg --alpha-config /oauth2-proxy.yaml
hostname: oauth2-proxy
volumes:
- "./oauth2-proxy.yaml:/oauth2-proxy.yaml"
- "./oauth2-proxy.cfg:/oauth2-proxy.cfg"
restart: unless-stopped
ports:
- 4180:4180/tcp
```
</details>
<details>
<summary>oauth2-proxy.cfg</summary>
```yaml
http_address="0.0.0.0:4180"
cookie_secret="OQINaROshtE9TcZkNAm-5Zs2Pv3xaWytBmc5W7sPX7w="
email_domains="example.com"
cookie_secure="false"
redirect_url="http://localhost:4180/oauth2/callback"
```
</details>
<details>
<summary>oauth2-proxy.yaml</summary>
```yaml
upstreams:
- id: open-webui
path: /
uri: http://open-webui:8080
injectRequestHeaders:
- name: X-Forwarded-Email
values:
- claim: email
providers:
# Provide a list of providers to use for authentication
# https://oauth2-proxy.github.io/oauth2-proxy/configuration/providers/
```
</details>
</details>
For anyone running Open WebUI inside of GCP, I've deployed [Identity Aware Proxy](https://cloud.google.com/security/products/iap) with [gcp-iap-auth](https://github.com/imkira/gcp-iap-auth) as a reverse proxy to extract the email from the JWT.
@cheahjs I believe a lot of people would find this tutorial useful, if you could make a PR here: https://github.com/open-webui/docs, we'd greatly appreciate it! Thanks for all the effort to make Open WebUI even better thus far!
<!-- gh-comment-id:2035735789 -->
@tjbck commented on GitHub (Apr 3, 2024):
@cheahjs I believe a lot of people would find this tutorial useful, if you could make a PR here: https://github.com/open-webui/docs, we'd greatly appreciate it! Thanks for all the effort to make Open WebUI even better thus far!
<!-- gh-comment-id:2037363448 -->
@cheahjs commented on GitHub (Apr 4, 2024):
> any luck setting this up with Authelia?
I don't currently have time to test out an Authelia deployment, but the docs for setting up the necessary headers is over at https://www.authelia.com/integration/trusted-header-sso/introduction/
@AsteroidOrangeJuice commented on GitHub (Apr 6, 2024):
@cellulosa I can confirm this works with Authelia with the Remote-Email header too! Thanks @cheahjs !!
<!-- gh-comment-id:2040989362 -->
@AsteroidOrangeJuice commented on GitHub (Apr 6, 2024):
@cellulosa I can confirm this works with Authelia with the Remote-Email header too! Thanks @cheahjs !!
Were {$MY_DOMAIN} can be hardcoded or passed as passed via docker-compose as:
environment:
- MY_DOMAIN=mywebsite.com
<!-- gh-comment-id:2045272965 -->
@cellulosa commented on GitHub (Apr 9, 2024):
> @cellulosa I can confirm this works with Authelia with the Remote-Email header too! Thanks @cheahjs !!
~~could you share your config? Thanks!~~
Nevermind, I managed! For all those interested:
Set the email header in `open-webui` in the `docker-compose` file:
```yml
open-webui:
environment:
- WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Remote-Email
```
Make sure to pass it in the `Caddyfile`:
```Caddyfile
{
servers {
trusted_proxies static private_ranges
}
}
(authelia) {
forward_auth authelia:9091 {
uri /api/verify?rd=https://auth.{$MY_DOMAIN}/
copy_headers Remote-Email
}
}
chat.{$MY_DOMAIN} {
import authelia
reverse_proxy open-webui:8080
}
```
Were `{$MY_DOMAIN}` can be hardcoded or passed as passed via docker-compose as:
```
environment:
- MY_DOMAIN=mywebsite.com
```
This sound absolutely fantastic! Is it possible to transmit the users role (admin, user etc) as trusted header, too?
<!-- gh-comment-id:2046664460 -->
@eingemaischt commented on GitHub (Apr 10, 2024):
This sound absolutely fantastic! Is it possible to transmit the users role (admin, user etc) as trusted header, too?
@Michelklingler commented on GitHub (Apr 29, 2024):
On my Side Woking well with Oauth2-proxy.
Only issue is that I can't log out for some reason.
Below is the working config to add to your docker compose:
### SERVICE : Oauth2-proxy - for SSO authentification with Google ###
oauth2-proxy:
image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0
hostname: oauth2-proxy
command: --custom-sign-in-logo https://YourLogo.png
environment:
OAUTH2_PROXY_HTTP_ADDRESS: 0.0.0.0:4180
OAUTH2_PROXY_UPSTREAMS: http://hostIp:8080/
OAUTH2_PROXY_CLIENT_ID: xxxx.apps.googleusercontent.com ### Exemple with google auth
OAUTH2_PROXY_CLIENT_SECRET: xxxx
OAUTH2_PROXY_EMAIL_DOMAINS: YourDomain
OAUTH2_PROXY_REDIRECT_URL: https://YourDomaine/oauth2/callback
OAUTH2_PROXY_COOKIE_SECRET: xxxx
OAUTH2_PROXY_COOKIE_SECURE: "false"
restart: unless-stopped
ports:
- 80:4180/tcp
**-> This is only the config on your host side.**
Make sure that all endpoints listed in this page are reachable in your domain from your Authenticator System (ex:google):
https://oauth2-proxy.github.io/oauth2-proxy/features/endpoints
<!-- gh-comment-id:2082593918 -->
@Michelklingler commented on GitHub (Apr 29, 2024):
On my Side Woking well with Oauth2-proxy.
Only issue is that I can't log out for some reason.
Below is the working config to add to your docker compose:
```
### SERVICE : Oauth2-proxy - for SSO authentification with Google ###
oauth2-proxy:
image: quay.io/oauth2-proxy/oauth2-proxy:v7.6.0
hostname: oauth2-proxy
command: --custom-sign-in-logo https://YourLogo.png
environment:
OAUTH2_PROXY_HTTP_ADDRESS: 0.0.0.0:4180
OAUTH2_PROXY_UPSTREAMS: http://hostIp:8080/
OAUTH2_PROXY_CLIENT_ID: xxxx.apps.googleusercontent.com ### Exemple with google auth
OAUTH2_PROXY_CLIENT_SECRET: xxxx
OAUTH2_PROXY_EMAIL_DOMAINS: YourDomain
OAUTH2_PROXY_REDIRECT_URL: https://YourDomaine/oauth2/callback
OAUTH2_PROXY_COOKIE_SECRET: xxxx
OAUTH2_PROXY_COOKIE_SECURE: "false"
restart: unless-stopped
ports:
- 80:4180/tcp
```
**-> This is only the config on your host side.**
Make sure that all endpoints listed in this page are reachable in your domain from your Authenticator System (ex:google):
https://oauth2-proxy.github.io/oauth2-proxy/features/endpoints
<!-- gh-comment-id:2088148767 -->
@hkng commented on GitHub (May 1, 2024):
For oauth2-proxy and keycloak, logout can be done by following url
```
open-webui signout location: https://<oauth2-proxy server>/oauth2/sign_out
keycloak logout location: https://<keycloak server>/auth/realms/<realms id>/protocol/openid-connect/logout
```
Refer to /src/routes/(app)/prompts/+layout.svelte, If we can find a way to change sign-out button as below, it may solve logout problem
```
<button
class="text-xs text-center w-full mt-2 text-gray-400 underline"
on:click={async () => {
localStorage.removeItem('token');
location.href = '/auth';
location.href = '/oauth2/sign_out';
location.href = 'https://<keycloak server>/auth/realms/<realms id>/protocol/openid-connect/logout'
}}>{$i18n.t('Sign Out')}</button
>
```
<!-- gh-comment-id:2101636863 -->
@sammcj commented on GitHub (May 8, 2024):
re: https://github.com/open-webui/open-webui/issues/483#issuecomment-2041216612
FYI Authentik auth seems to now be broken with the release of v0.1.124.
Tried with both the same config as I had for v0.1.123 (auth enabled), and with a fresh deployment with empty DB etc... and auth disabled.
I suspect it has something to do with this: https://github.com/open-webui/open-webui/issues/929#issuecomment-2101623934
@sammcj Just pushed a fix for trusted header support, let me know if the issue persists!
<!-- gh-comment-id:2101652727 -->
@tjbck commented on GitHub (May 8, 2024):
@sammcj Just pushed a fix for trusted header support, let me know if the issue persists!
<!-- gh-comment-id:2101665749 -->
@sammcj commented on GitHub (May 8, 2024):
comment moved to https://github.com/open-webui/open-webui/issues/929#issuecomment-2101667151
@NathanAdhitya commented on GitHub (May 20, 2024):
As mentioned by hkng, I think a post-logout redirect is needed.
Currently, with oauth2-proxy, the sign out button does not work.
For the sake of completeness, a mechanism to correctly change the user when the user of the current token mismatches the trusted email header would be nice. As of now, changing the header value does not cause open-webui to change user until the sign out button is clicked.
<!-- gh-comment-id:2120496284 -->
@NathanAdhitya commented on GitHub (May 20, 2024):
As mentioned by hkng, I think a post-logout redirect is needed.
Currently, with oauth2-proxy, the sign out button does not work.
For the sake of completeness, a mechanism to correctly change the user when the user of the current token mismatches the trusted email header would be nice. As of now, changing the header value does not cause open-webui to change user until the sign out button is clicked.
So I think my headers are getting set, but when I visit openwebui I see:
You do not have permission to access this resource. Please contact your administrator for assistance.
<!-- gh-comment-id:2132413830 -->
@Macmee commented on GitHub (May 26, 2024):
Hi! I was wondering if oauth2-proxy is still working (or probably im just setting it up wrong!)
when I visit mydomain.com/oauth2/auth I can see these headers:
```
Gap-Auth: my@email.com
X-Auth-Request-Email: my@email.com
```
and ive tried setting both of these in docker-compose like:
```
environment:
- 'WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-Auth-Request-Email'
```
So I _think_ my headers are getting set, but when I visit openwebui I see:
> You do not have permission to access this resource. Please contact your administrator for assistance.
Is there a way to redirect the user after a successful authentication using WEBUI_AUTH_TRUSTED_EMAIL_HEADER?
For example, I have my Open WebUI embedded in an html block of a Moodle instance (seperate server) which utilizes a PHP script to call http://localhost:3001/api/v1/auths/signin with the appropriate post, headers, and json data however I am not redirected. I do see the user created and I am returned the new user data (username, email, token, etc.), just no redirect. I am not using tailescale nor cloudlfar, just the generic configurationl
<!-- gh-comment-id:2153065235 -->
@LopezRoman commented on GitHub (Jun 6, 2024):
Is there a way to redirect the user after a successful authentication using `WEBUI_AUTH_TRUSTED_EMAIL_HEADER`?
For example, I have my Open WebUI embedded in an html block of a Moodle instance (seperate server) which utilizes a PHP script to call `http://localhost:3001/api/v1/auths/signin` with the appropriate post, headers, and json data however I am not redirected. I do see the user created and I am returned the new user data (username, email, token, etc.), just no redirect. I am not using tailescale nor cloudlfar, just the [generic configurationl](https://docs.openwebui.com/tutorial/sso/#generic-configurationl)
im confused. The Documentation says a lot about ENV variables for OAuth. For instance:
ENABLE_OAUTH_SIGNUP
OAUTH_CLIENT_SECRET
etc.
Yet when I add my Authentik OAuth settings in there. Nothing happens. And considering the lack of topics about this, Im confused as to if it actually even exists?
Why does it say it here? https://docs.openwebui.com/getting-started/env-configuration/#oauth
<!-- gh-comment-id:2207092422 -->
@keesfluitman commented on GitHub (Jul 3, 2024):
im confused. The Documentation says a lot about ENV variables for OAuth. For instance:
ENABLE_OAUTH_SIGNUP
OAUTH_CLIENT_SECRET
etc.
Yet when I add my Authentik OAuth settings in there. Nothing happens. And considering the lack of topics about this, Im confused as to if it actually even exists?
Why does it say it here?
https://docs.openwebui.com/getting-started/env-configuration/#oauth
I'm trying to set this up with Authelia. It redirects to Authelia fine, but the redirect URL for OpenWebUI itself is always http:// instead of https://. I have session cookie security set to secure, which makes the oauth client https_only. Why would it attempt to callback to an HTTP URL?
Edit: answered my own question. Needed to make sure that the HTTP protocol was forwarded in nginx.
<!-- gh-comment-id:2222663932 -->
@ProjectMoon commented on GitHub (Jul 11, 2024):
I'm trying to set this up with Authelia. It redirects to Authelia fine, but the redirect URL for OpenWebUI itself is always `http://` instead of `https://`. I have session cookie security set to secure, which makes the oauth client `https_only`. Why would it attempt to callback to an HTTP URL?
Edit: answered my own question. Needed to make sure that the HTTP protocol was forwarded in nginx.
@christiangierschner commented on GitHub (Jul 23, 2024):
Hi,
I successfully set up OAUTH with Keycloak. Is there a way to disable the native open-webui login and get redirected straight to Keycloak. So users don't get confused or don't use the button below the login fields?
<!-- gh-comment-id:2244785182 -->
@christiangierschner commented on GitHub (Jul 23, 2024):
Hi,
I successfully set up OAUTH with Keycloak. Is there a way to disable the native open-webui login and get redirected straight to Keycloak. So users don't get confused or don't use the button below the login fields?
<!-- gh-comment-id:2250220508 -->
@christiangierschner commented on GitHub (Jul 25, 2024):
Nice! Thank you so much...i will try it
I would love an automatic forward to OAuth when opening webui url if
```
ENABLE_OAUTH_SIGNUP: true
ENABLE_LOGIN_FORM: false
```
OAUTH i get a middleware error. Using Authentik. Everything should be right but nothing works.
Trusted header works partly, it logs in, but then doesn't use the received token to further request.
Can anyone help me? Im at a loss here. I read about how easy it is, etc. But it's just refusing to work.
<!-- gh-comment-id:2254473510 -->
@keesfluitman commented on GitHub (Jul 28, 2024):
OAUTH i get a middleware error. Using Authentik. Everything should be right but nothing works.
Trusted header works partly, it logs in, but then doesn't use the received token to further request.
```
open-webui | INFO: 2001:1711:fa46:3bc0:9d5c:11cd:b1ab:758:0 - "GET /api/v1/configs/banners HTTP/1.1" 403 Forbidden
open-webui | INFO: 2001:1711:fa46:3bc0:9d5c:11cd:b1ab:758:0 - "GET /api/models HTTP/1.1" 403 Forbidden
open-webui | INFO: 2001:1711:fa46:3bc0:9d5c:11cd:b1ab:758:0 - "GET /api/v1/documents/ HTTP/1.1" 403 Forbidden
open-webui | INFO: 2001:1711:fa46:3bc0:9d5c:11cd:b1ab:758:0 - "GET /api/v1/tools/ HTTP/1.1" 403 Forbidden
open-webui | INFO: 2001:1711:fa46:3bc0:9d5c:11cd:b1ab:758:0 - "GET /api/v1/chats/tags/all HTTP/1.1" 403 Forbidden
open-webui | INFO: 2001:1711:fa46:3bc0:9d5c:11cd:b1ab:758:0 - "GET /api/v1/prompts/ HTTP/1.1" 403 Forbidden
```
```
# OAuth credentials
OAUTH_CLIENT_ID=ID
OAUTH_CLIENT_SECRET=SECRET
# OpenID provider URL
OPENID_PROVIDER_URL=https://authentik.domain.com/application/o/oidc-openwebui/.well-known/openid-configuration
# OAuth provider name
OAUTH_PROVIDER_NAME=Authentik
# OAuth scopes
OAUTH_SCOPES=email profile
ENABLE_OAUTH_SIGNUP=true
OAUTH_MERGE_ACCOUNTS_BY_EMAIL=false
```
Can anyone help me? Im at a loss here. I read about how easy it is, etc. But it's just refusing to work.
@senpro-ingwersenk commented on GitHub (Aug 1, 2024):
@christiangierschner Mind sharing your settings? Running into this:
openwebui | WARNI [main] OAuth callback error: mismatching_state: CSRF Warning! State not equal in request and response.
(... and later ...)
openwebui | WARNI [main] OAuth callback error: Expecting value: line 1 column 1 (char 0)
(Context: Test server running in plain HTTP vs. Keycloak in Kubernetes in HTTPS, not sure if it matters or not...)
The error that I see on screen is:
{"detail":"The email or password provided is incorrect. Please check for typos and try logging in again."}
Thanks!
<!-- gh-comment-id:2262345930 -->
@senpro-ingwersenk commented on GitHub (Aug 1, 2024):
@christiangierschner Mind sharing your settings? Running into this:
```
openwebui | WARNI [main] OAuth callback error: mismatching_state: CSRF Warning! State not equal in request and response.
(... and later ...)
openwebui | WARNI [main] OAuth callback error: Expecting value: line 1 column 1 (char 0)
```
(Context: Test server running in plain HTTP vs. Keycloak in Kubernetes in HTTPS, not sure if it matters or not...)
The error that I see on screen is:
```json
{
"detail": "The email or password provided is incorrect. Please check for typos and try logging in again."
}
```
Thanks!
Works for me using Open WebUI w/ Docker (on Cloudron) and Authentik. Simply create your app and provider in Authentik, then fill in the variables:
<!-- gh-comment-id:2286710989 -->
@Lanhild commented on GitHub (Aug 13, 2024):
Works for me using Open WebUI w/ Docker (on Cloudron) and Authentik. Simply create your app and provider in Authentik, then fill in the variables:
For folks using a more traditional setup of SAML authentication with Apache & Shibboleth on Linux, I'm wondering if there is a use case or mechanism for exposing Shibboleth attributes as the trusted headers!
<!-- gh-comment-id:2299579426 -->
@atnjqt commented on GitHub (Aug 20, 2024):
For folks using a more traditional setup of SAML authentication with Apache & Shibboleth on Linux, I'm wondering if there is a use case or mechanism for exposing Shibboleth attributes as the trusted headers!
@senpro-ingwersenk did you solve your problem?
I am seeing the same error response when trying to authenticate via oidc (Keycloak)
<!-- gh-comment-id:2302908656 -->
@brtptrs commented on GitHub (Aug 21, 2024):
@senpro-ingwersenk did you solve your problem?
I am seeing the same error response when trying to authenticate via oidc (Keycloak)
@senpro-ingwersenk commented on GitHub (Aug 22, 2024):
@brtptrs Sadly no I am afraid... Haven't had an idea how to debug it either - my last resort would've been to drop wireshark between the two and see what comes out. But other than that I am rather clueless to be honest. The other thing I might try is to make Traefik in our k3s cluster be more detailed for Keycloak - in terms of access logs. Maybe this tells me something...? Other than that, I have no real idea tbh ^^;
<!-- gh-comment-id:2303752448 -->
@senpro-ingwersenk commented on GitHub (Aug 22, 2024):
@brtptrs Sadly no I am afraid... Haven't had an idea how to debug it either - my last resort would've been to drop wireshark between the two and see what comes out. But other than that I am rather clueless to be honest. The other thing I might try is to make Traefik in our k3s cluster be more detailed for Keycloak - in terms of access logs. Maybe this tells me something...? Other than that, I have no real idea tbh ^^;
Thanks for the feedback.
I've enabled debugging and am seeing these entries in the logs:
INFO: 79.220.58.87:0 - "GET /oauth/oidc/login HTTP/1.1" 302 Found
DEBUG [main] Commit session after request
INFO: 79.220.58.87:0 - "GET /oauth/oidc/callback?state=xxxxxxxxxxxxxxxxx&session_state=cabdac81-yyyyyyyyyyyyyyy&code=zzzzzzzzzzzzzzzzzzzzzz.cabdac81-yyyyyyyyyyyyyyy.qqqqqqqqqq HTTP/1.1" 307 Temporary Redirect
WARNI [main] OAuth callback error: mismatching_state: CSRF Warning! State not equal in request and response.
DEBUG [main] Commit session after request
INFO: 79.220.58.87:0 - "GET /oauth/oidc/callback?state=xxxxxxxxxxxxxxxxx&session_state=cabdac81-yyyyyyyyyyyyyyy&code=zzzzzzzzzzzzzzzzzzzzzz.cabdac81-yyyyyyyyyyyyyyy.qqqqqqqqqq HTTP/1.1" 400 Bad Request
Unfortunately, I don't know what to make of it.
On our setup, OpenWebui is running in a docker container behind an Apache reverse -proxy. Maybe that has something to do with the problem.
On oidc login, the user is correctly redirected to KeyCloak and then back to OpenWebUI after a successful login.
Maybe we should open a new ticket for this.
<!-- gh-comment-id:2304133760 -->
@brtptrs commented on GitHub (Aug 22, 2024):
Thanks for the feedback.
I've enabled debugging and am seeing these entries in the logs:
INFO: 79.220.58.87:0 - "GET /oauth/oidc/login HTTP/1.1" 302 Found
DEBUG [main] Commit session after request
INFO: 79.220.58.87:0 - "GET /oauth/oidc/callback?state=xxxxxxxxxxxxxxxxx&session_state=cabdac81-yyyyyyyyyyyyyyy&code=zzzzzzzzzzzzzzzzzzzzzz.cabdac81-yyyyyyyyyyyyyyy.qqqqqqqqqq HTTP/1.1" 307 Temporary Redirect
WARNI [main] OAuth callback error: mismatching_state: CSRF Warning! State not equal in request and response.
DEBUG [main] Commit session after request
INFO: 79.220.58.87:0 - "GET /oauth/oidc/callback?state=xxxxxxxxxxxxxxxxx&session_state=cabdac81-yyyyyyyyyyyyyyy&code=zzzzzzzzzzzzzzzzzzzzzz.cabdac81-yyyyyyyyyyyyyyy.qqqqqqqqqq HTTP/1.1" 400 Bad Request
Unfortunately, I don't know what to make of it.
On our setup, OpenWebui is running in a docker container behind an Apache reverse -proxy. Maybe that has something to do with the problem.
On oidc login, the user is correctly redirected to KeyCloak and then back to OpenWebUI after a successful login.
Maybe we should open a new ticket for this.
So I think my headers are getting set, but when I visit openwebui I see:
You do not have permission to access this resource. Please contact your administrator for assistance.
@Macmee Have you ever figured out a solution? I am getting the same answer from my Synology SSO server using OIDC service:
{ "detail": "You do not have permission to access this resource. Please contact your administrator for assistance." }
I set the following scopes according to the specifications of the server. Everything else including the default scopes would give me an internal server error.
- OAUTH_SCOPES=openid email username
edit: silly me, I forgot to add the environment variable to enable oauth, and it works now:
ENABLE_OAUTH_SIGNUP=true
<!-- gh-comment-id:2307556177 -->
@aeonoea commented on GitHub (Aug 23, 2024):
> Hi! I was wondering if oauth2-proxy is still working (or probably im just setting it up wrong!)
>
> when I visit mydomain.com/oauth2/auth I can see these headers:
>
> ```
> Gap-Auth: my@email.com
> X-Auth-Request-Email: my@email.com
> ```
>
> and ive tried setting both of these in docker-compose like:
>
> ```
> environment:
> - 'WEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-Auth-Request-Email'
> ```
>
> So I _think_ my headers are getting set, but when I visit openwebui I see:
>
> > You do not have permission to access this resource. Please contact your administrator for assistance.
@Macmee Have you ever figured out a solution? I am getting the same answer from my Synology SSO server using OIDC service:
`{
"detail": "You do not have permission to access this resource. Please contact your administrator for assistance."
}`
I set the following scopes according to the specifications of the server. Everything else including the default scopes would give me an internal server error.
` - OAUTH_SCOPES=openid email username
`
edit: silly me, I forgot to add the environment variable to enable oauth, and it works now:
`ENABLE_OAUTH_SIGNUP=true`
As mentioned by hkng, I think a post-logout redirect is needed. Currently, with oauth2-proxy, the sign out button does not work.
For the sake of completeness, a mechanism to correctly change the user when the user of the current token mismatches the trusted email header would be nice. As of now, changing the header value does not cause open-webui to change user until the sign out button is clicked.
In my case (Openwebui+Nginx Proxy Manager+Oauth2-proxy) I just use Advance host config
logic is if user requested to ai.mydomain.com/auth then redirect to ai.mydomain.com/oauth2/sign_out. working fine didn't see issue yet. let me know if you got better one.
<!-- gh-comment-id:2323003848 -->
@utilitee commented on GitHub (Aug 31, 2024):
> As mentioned by hkng, I think a post-logout redirect is needed. Currently, with oauth2-proxy, the sign out button does not work.
>
> For the sake of completeness, a mechanism to correctly change the user when the user of the current token mismatches the trusted email header would be nice. As of now, changing the header value does not cause open-webui to change user until the sign out button is clicked.
In my case (Openwebui+Nginx Proxy Manager+Oauth2-proxy) I just use Advance host config
```
location = /auth {
rewrite ^ /oauth2/sign_out redirect;
}
```
logic is if user requested to ai.mydomain.com/auth then redirect to ai.mydomain.com/oauth2/sign_out. working fine didn't see issue yet. let me know if you got better one.
For me, user have to clear cache after successfully register and before first login, otherwise the web page will keep refresh, still not knowing why
<!-- gh-comment-id:2326802293 -->
@luochen1990 commented on GitHub (Sep 3, 2024):
For me, user have to clear cache after successfully register and before first login, otherwise the web page will keep refresh, still not knowing why
Works for me using Open WebUI w/ Docker (on Cloudron) and Authentik. Simply create your app and provider in Authentik, then fill in the variables:
<!-- gh-comment-id:2393960351 -->
@emgitadm commented on GitHub (Oct 4, 2024):
> Works for me using Open WebUI w/ Docker (on Cloudron) and Authentik. Simply create your app and provider in Authentik, then fill in the variables:
>
> 
Where and how can I set the variables? my setup is using docker hosted on a virtual machine (local machine and Authentik?
<!-- gh-comment-id:2393962488 -->
@emgitadm commented on GitHub (Oct 4, 2024):
Where and how can I set the variables? my setup is using docker hosted on a virtual machine (local machine and Authentik?
I'm trying to set this up with Authelia. It redirects to Authelia fine, but the redirect URL for OpenWebUI itself is always http:// instead of https://. I have session cookie security set to secure, which makes the oauth client https_only. Why would it attempt to callback to an HTTP URL?
Edit: answered my own question. Needed to make sure that the HTTP protocol was forwarded in nginx.
Can you elaborate on this? Running into the same issue. Do I need to do something at the proxy level (HAProxy running on pfSense)? I haven't had to do that for other apps using Authentik for OIDC all going out the main pipe (external domains rather than internal IPs)
<!-- gh-comment-id:2410509715 -->
@nwithan8 commented on GitHub (Oct 14, 2024):
> I'm trying to set this up with Authelia. It redirects to Authelia fine, but the redirect URL for OpenWebUI itself is always `http://` instead of `https://`. I have session cookie security set to secure, which makes the oauth client `https_only`. Why would it attempt to callback to an HTTP URL?
>
> Edit: answered my own question. Needed to make sure that the HTTP protocol was forwarded in nginx.
Can you elaborate on this? Running into the same issue. Do I need to do something at the proxy level (HAProxy running on pfSense)? I haven't had to do that for other apps using Authentik for OIDC all going out the main pipe (external domains rather than internal IPs)
Hi @christiangierschner, were you able to achieve the desired result with the automatic redirect to Keycloak when opening the Open WebUI URL? Thank you!"
<!-- gh-comment-id:2471175047 -->
@alimaskin commented on GitHub (Nov 12, 2024):
> Nice! Thank you so much...i will try it I would love an automatic forward to OAuth when opening webui url if
>
> ```
> ENABLE_OAUTH_SIGNUP: true
> ENABLE_LOGIN_FORM: false
> ```
Hi @christiangierschner, were you able to achieve the desired result with the automatic redirect to Keycloak when opening the Open WebUI URL? Thank you!"
I was wondering this too, that last thing missing is an "auto login"/ "auto redirect" to auto trigger the OIDC flow
<!-- gh-comment-id:2533779237 -->
@phyzical commented on GitHub (Dec 11, 2024):
I was wondering this too, that last thing missing is an "auto login"/ "auto redirect" to auto trigger the OIDC flow
@christiangierschner commented on GitHub (Jan 6, 2025):
Hi, Unfortunately not. Our Users have to click on the login button...would love this though...
<!-- gh-comment-id:2572653984 -->
@christiangierschner commented on GitHub (Jan 6, 2025):
Hi, Unfortunately not. Our Users have to click on the login button...would love this though...
Hi, Unfortunately not. Our Users have to click on the login button...would love this though...
<!-- gh-comment-id:2595902898 -->
@voc0der commented on GitHub (Jan 16, 2025):
Same here
> Hi, Unfortunately not. Our Users have to click on the login button...would love this though...
@phyzical & @christiangierschner I've gotten around this auto-login functionality with implementing a passive Shibboleth & Apache reverse proxy setup.
For all routes besides /auth (and also the /favicon which was throwing some strange CORS errors in browser console) this is setup passively.
A new user hits my app, the app seemingly redirects the frontend to /auth_ but this isn't actually a 301 or 302 redirection to the backend proxy.
Thus the user needs to refresh the page on /auth one time, which then hits the proxy as my only active shibboleth route, which initiates the call to the IDP which then returns the necessary RequestHeaders I'm mapping to env vars for authorized email domains. I imagine the OIDC flow is similar to a Shibboleth setup!
Really if the app did a proper redirect to that /auth route, instead of just updating the client-side browser URL to have this, it'd work like a login!
Here is a sample of that apache config:
<Location /Shibboleth.sso>
AuthType None
Require all granted
</Location>
<Location />
AuthType shibboleth
ShibRequestSetting requireSession false
ShibRequestSetting isPassive true
ShibUseHeaders on
Require shibboleth
</Location>
<Location /auth>
AuthType shibboleth
ShibUseEnvironment on
ShibRequestSetting requireSession true
ShibRequestSetting isPassive false
ShibUseHeaders off
Require shib-session
</Location>
# Exclude favicon.ico from Shibboleth authentication
<Location "/favicon">
AuthType None
Require all granted
</Location>
RequestHeader set HTTP_eduPersonPrincipalName %{eppn}e
RequestHeader set HTTP_givenName %{givenName}e
RequestHeader set HTTP_sn %{sn}e
RequestHeader set HTTP_fullName "%{givenName}e %{sn}e"
<!-- gh-comment-id:2595948880 -->
@atnjqt commented on GitHub (Jan 16, 2025):
@phyzical & @christiangierschner I've gotten around this auto-login functionality with implementing a passive Shibboleth & Apache reverse proxy setup.
For all routes besides `/auth` (and also the `/favicon` which was throwing some strange CORS errors in browser console) this is setup passively.
A new user hits my app, the app seemingly redirects _the frontend to `/auth`__ but this isn't actually a 301 or 302 redirection to the backend proxy.
Thus the user needs to refresh the page on `/auth` one time, which then hits the proxy as my only active shibboleth route, which initiates the call to the IDP which then returns the necessary **RequestHeaders** I'm mapping to env vars for authorized email domains. I imagine the OIDC flow is similar to a Shibboleth setup!
Really if the app did a proper redirect to that `/auth` route, instead of just updating the client-side browser URL to have this, it'd work like a login!
Here is a sample of that apache config:
```
<Location /Shibboleth.sso>
AuthType None
Require all granted
</Location>
<Location />
AuthType shibboleth
ShibRequestSetting requireSession false
ShibRequestSetting isPassive true
ShibUseHeaders on
Require shibboleth
</Location>
<Location /auth>
AuthType shibboleth
ShibUseEnvironment on
ShibRequestSetting requireSession true
ShibRequestSetting isPassive false
ShibUseHeaders off
Require shib-session
</Location>
# Exclude favicon.ico from Shibboleth authentication
<Location "/favicon">
AuthType None
Require all granted
</Location>
RequestHeader set HTTP_eduPersonPrincipalName %{eppn}e
RequestHeader set HTTP_givenName %{givenName}e
RequestHeader set HTTP_sn %{sn}e
RequestHeader set HTTP_fullName "%{givenName}e %{sn}e"
```
<!-- gh-comment-id:2658216399 -->
@arunbugkiller commented on GitHub (Feb 14, 2025):
I think you would be able to solve most of the problems with below environment variables. Please do try it out
-e ENABLE_OAUTH_SIGNUP=true -e WEBUI_SESSION_COOKIE_SAME_SITE=lax -e WEBUI_AUTH_COOKIE_SAME_SITE=lax -e ENABLE_LOGIN_FORM=True -e OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Originally created by @Kryszn0 on GitHub (Jan 15, 2024).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/483
Is your feature request related to a problem? Please describe.
Add feature to enable account creation via OAuth/OIDC
Describe the solution you'd like
Integrating ollama-webui with auth providers such as Authentik, Keycloak, etc
Describe alternatives you've considered
N/A
Additional context
Being able to create a local account as an admin upon initialization should remain, but afterwards the admin account should be able to add the relevant information to change the default login page to redirect to a self-hosted OAuth/OIDC provider
@tjbck commented on GitHub (Jan 15, 2024):
Related: #340
@mafrasiabi commented on GitHub (Jan 19, 2024):
It would be very good to have integration with AzureAD too.
@josh commented on GitHub (Jan 28, 2024):
Ever since the new user accounts were rolled out, I've been wanting some kind of way to delegate auth as well.
In my specific case, my ollama-webui is behind a Tailscale VPN. They have a pretty lightweight set of trusted identity headers when proxied to. It seems like a few other SSO providers like Authelia can be configured to pass along trusted headers.
From the ollama-webui side, you'd configure some envvar like
OLLAMA_AUTH_TRUSTED_HEADER=X-Remote-Userto enable this delegated auth mode. The Python backend would look for this header and automatically log in or create an account for the user given in the header value.I wondering if this approach would cover your auth use cases as well? If so, I might take a stab at a PR implementation.
@explorigin commented on GitHub (Feb 9, 2024):
Just a heads up. I'm working on integrating https://fastapi-users.github.io/fastapi-users/latest/ into ollama-webui. That will give us OAUTH2 for these clients: https://frankie567.github.io/httpx-oauth/oauth2/#provided-clients. Give me a few weeks.
@elvis-cai commented on GitHub (Feb 26, 2024):
thanks @explorigin 🙇 it will be a killer feature in the open llm UI market.
I am keen to have this feature for demo in the coming weeks, if you don't mind, Could I know if there's any estimation for it available?
@explorigin commented on GitHub (Feb 26, 2024):
Sorry, no estimate. I started on it but work/life got crazy. If you need it for work then work on it. I've started with fastapi-users library but that has some considerations:
And that's all before getting to the Oauth configuration that needs to be exposed in a smart manner. So it's not a simple feature.
@aitzubi commented on GitHub (Mar 7, 2024):
I will be interested on testing this when it is available. It would be great to add an option to automatically verify users based on their domain.
Keep the good job guys!
@m00nwtchr commented on GitHub (Mar 10, 2024):
+1 for auth via Forwarded Headers, for many selfhosted setups OIDC/OAuth is pretty overkill. (Though still very useful for public instances)
@cheahjs commented on GitHub (Mar 26, 2024):
Not quite what was asked for with OAuth/OIDC for the actual auth, but I've yolo'd in a patch for my own use case with trusted headers, https://github.com/open-webui/open-webui/compare/dev...cheahjs:open-webui-fork:feat/trusted-email-header
Users will still have to enter their email addresses to sign up and sign in(I've implemented automatic registration and sign in for users that have been authed by the header), but I've tested it withWEBUI_AUTH_TRUSTED_EMAIL_HEADER=Tailscale-User-Loginfor Tailscale Serve, andWEBUI_AUTH_TRUSTED_EMAIL_HEADER=X-WebAuth-Userwith gcp-iap-auth + Google Clouds's Identity Aware Proxy@explorigin commented on GitHub (Mar 26, 2024):
Yep, I announced and then ghosted. Sorry. Going through a job change. Don't count on me for this.
@cheahjs commented on GitHub (Apr 3, 2024):
Given the newly merged trusted email header feature, Open WebUI doesn't support federated auth by itself, but it can offload auth to a authenticating proxy. Some example compose stacks (these are not exactly production ready, remember to harden where necessary with your own secrets):
Tailscale Serve
Starts Tailscale as a sidecar, and exposes Open WebUI via Tailscale Serve. Authorization should be handled using your tailnet's ACL rules.
docker-compose.yaml
tailscale-serve.json
oauth2-proxy
oauth2-proxysupports multiple OAuth providers and OIDC (list of providers). You will need to configure the providers and how to handle authorization yourself. I have not tested this.docker-compose.yaml
oauth2-proxy.cfg
oauth2-proxy.yaml
For anyone running Open WebUI inside of GCP, I've deployed Identity Aware Proxy with gcp-iap-auth as a reverse proxy to extract the email from the JWT.
@tjbck commented on GitHub (Apr 3, 2024):
@cheahjs I believe a lot of people would find this tutorial useful, if you could make a PR here: https://github.com/open-webui/docs, we'd greatly appreciate it! Thanks for all the effort to make Open WebUI even better thus far!
@Michelklingler commented on GitHub (Apr 3, 2024):
I agree super well done documentation!
Thanks a lot!
@cellulosa commented on GitHub (Apr 4, 2024):
any luck setting this up with Authelia?
@cheahjs commented on GitHub (Apr 4, 2024):
I don't currently have time to test out an Authelia deployment, but the docs for setting up the necessary headers is over at https://www.authelia.com/integration/trusted-header-sso/introduction/
@AsteroidOrangeJuice commented on GitHub (Apr 6, 2024):
@cellulosa I can confirm this works with Authelia with the Remote-Email header too! Thanks @cheahjs !!
@sammcj commented on GitHub (Apr 6, 2024):
Confirmed I've got this working with Traefik + Authentik 🎉
Large example available here: https://github.com/open-webui/open-webui/issues/929#issuecomment-2041296801
@cellulosa commented on GitHub (Apr 9, 2024):
could you share your config? Thanks!Nevermind, I managed! For all those interested:
Set the email header in
open-webuiin thedocker-composefile:Make sure to pass it in the
Caddyfile:Were
{$MY_DOMAIN}can be hardcoded or passed as passed via docker-compose as:@eingemaischt commented on GitHub (Apr 10, 2024):
This sound absolutely fantastic! Is it possible to transmit the users role (admin, user etc) as trusted header, too?
@aitzubi commented on GitHub (Apr 29, 2024):
Anybody knows how to implement this using Keycloak?
@Michelklingler commented on GitHub (Apr 29, 2024):
On my Side Woking well with Oauth2-proxy.
Only issue is that I can't log out for some reason.
Below is the working config to add to your docker compose:
@hkng commented on GitHub (May 1, 2024):
For oauth2-proxy and keycloak, logout can be done by following url
Refer to /src/routes/(app)/prompts/+layout.svelte, If we can find a way to change sign-out button as below, it may solve logout problem
@sammcj commented on GitHub (May 8, 2024):
re: https://github.com/open-webui/open-webui/issues/483#issuecomment-2041216612
FYI Authentik auth seems to now be broken with the release of v0.1.124.
Tried with both the same config as I had for v0.1.123 (auth enabled), and with a fresh deployment with empty DB etc... and auth disabled.
I suspect it has something to do with this: https://github.com/open-webui/open-webui/issues/929#issuecomment-2101623934
@tjbck commented on GitHub (May 8, 2024):
@sammcj Just pushed a fix for trusted header support, let me know if the issue persists!
@sammcj commented on GitHub (May 8, 2024):
comment moved to https://github.com/open-webui/open-webui/issues/929#issuecomment-2101667151
@NathanAdhitya commented on GitHub (May 20, 2024):
As mentioned by hkng, I think a post-logout redirect is needed.
Currently, with oauth2-proxy, the sign out button does not work.
For the sake of completeness, a mechanism to correctly change the user when the user of the current token mismatches the trusted email header would be nice. As of now, changing the header value does not cause open-webui to change user until the sign out button is clicked.
@Macmee commented on GitHub (May 26, 2024):
Hi! I was wondering if oauth2-proxy is still working (or probably im just setting it up wrong!)
when I visit mydomain.com/oauth2/auth I can see these headers:
and ive tried setting both of these in docker-compose like:
So I think my headers are getting set, but when I visit openwebui I see:
@LopezRoman commented on GitHub (Jun 6, 2024):
Is there a way to redirect the user after a successful authentication using
WEBUI_AUTH_TRUSTED_EMAIL_HEADER?For example, I have my Open WebUI embedded in an html block of a Moodle instance (seperate server) which utilizes a PHP script to call
http://localhost:3001/api/v1/auths/signinwith the appropriate post, headers, and json data however I am not redirected. I do see the user created and I am returned the new user data (username, email, token, etc.), just no redirect. I am not using tailescale nor cloudlfar, just the generic configurationl@keesfluitman commented on GitHub (Jul 3, 2024):
im confused. The Documentation says a lot about ENV variables for OAuth. For instance:
ENABLE_OAUTH_SIGNUP
OAUTH_CLIENT_SECRET
etc.
Yet when I add my Authentik OAuth settings in there. Nothing happens. And considering the lack of topics about this, Im confused as to if it actually even exists?
Why does it say it here?
https://docs.openwebui.com/getting-started/env-configuration/#oauth
@ProjectMoon commented on GitHub (Jul 11, 2024):
I'm trying to set this up with Authelia. It redirects to Authelia fine, but the redirect URL for OpenWebUI itself is always
http://instead ofhttps://. I have session cookie security set to secure, which makes the oauth clienthttps_only. Why would it attempt to callback to an HTTP URL?Edit: answered my own question. Needed to make sure that the HTTP protocol was forwarded in nginx.
@christiangierschner commented on GitHub (Jul 23, 2024):
Hi,
I successfully set up OAUTH with Keycloak. Is there a way to disable the native open-webui login and get redirected straight to Keycloak. So users don't get confused or don't use the button below the login fields?
@Louden7 commented on GitHub (Jul 25, 2024):
@christiangierschner check out #4068 as it might satisfy your request.
@christiangierschner commented on GitHub (Jul 25, 2024):
Nice! Thank you so much...i will try it
I would love an automatic forward to OAuth when opening webui url if
@keesfluitman commented on GitHub (Jul 28, 2024):
OAUTH i get a middleware error. Using Authentik. Everything should be right but nothing works.
Trusted header works partly, it logs in, but then doesn't use the received token to further request.
Can anyone help me? Im at a loss here. I read about how easy it is, etc. But it's just refusing to work.
@senpro-ingwersenk commented on GitHub (Aug 1, 2024):
@christiangierschner Mind sharing your settings? Running into this:
(Context: Test server running in plain HTTP vs. Keycloak in Kubernetes in HTTPS, not sure if it matters or not...)
The error that I see on screen is:
Thanks!
@christiangierschner commented on GitHub (Aug 6, 2024):
i didnt do any magic it worked right out of the box...
we have a docker host with traefik + local acme for https certificate
@Lanhild commented on GitHub (Aug 13, 2024):
Works for me using Open WebUI w/ Docker (on Cloudron) and Authentik. Simply create your app and provider in Authentik, then fill in the variables:
@atnjqt commented on GitHub (Aug 20, 2024):
For folks using a more traditional setup of SAML authentication with Apache & Shibboleth on Linux, I'm wondering if there is a use case or mechanism for exposing Shibboleth attributes as the trusted headers!
@brtptrs commented on GitHub (Aug 21, 2024):
@senpro-ingwersenk did you solve your problem?
I am seeing the same error response when trying to authenticate via oidc (Keycloak)
@senpro-ingwersenk commented on GitHub (Aug 22, 2024):
@brtptrs Sadly no I am afraid... Haven't had an idea how to debug it either - my last resort would've been to drop wireshark between the two and see what comes out. But other than that I am rather clueless to be honest. The other thing I might try is to make Traefik in our k3s cluster be more detailed for Keycloak - in terms of access logs. Maybe this tells me something...? Other than that, I have no real idea tbh ^^;
@brtptrs commented on GitHub (Aug 22, 2024):
Thanks for the feedback.
I've enabled debugging and am seeing these entries in the logs:
INFO: 79.220.58.87:0 - "GET /oauth/oidc/login HTTP/1.1" 302 Found
DEBUG [main] Commit session after request
INFO: 79.220.58.87:0 - "GET /oauth/oidc/callback?state=xxxxxxxxxxxxxxxxx&session_state=cabdac81-yyyyyyyyyyyyyyy&code=zzzzzzzzzzzzzzzzzzzzzz.cabdac81-yyyyyyyyyyyyyyy.qqqqqqqqqq HTTP/1.1" 307 Temporary Redirect
WARNI [main] OAuth callback error: mismatching_state: CSRF Warning! State not equal in request and response.
DEBUG [main] Commit session after request
INFO: 79.220.58.87:0 - "GET /oauth/oidc/callback?state=xxxxxxxxxxxxxxxxx&session_state=cabdac81-yyyyyyyyyyyyyyy&code=zzzzzzzzzzzzzzzzzzzzzz.cabdac81-yyyyyyyyyyyyyyy.qqqqqqqqqq HTTP/1.1" 400 Bad Request
Unfortunately, I don't know what to make of it.
On our setup, OpenWebui is running in a docker container behind an Apache reverse -proxy. Maybe that has something to do with the problem.
On oidc login, the user is correctly redirected to KeyCloak and then back to OpenWebUI after a successful login.
Maybe we should open a new ticket for this.
@aeonoea commented on GitHub (Aug 23, 2024):
@Macmee Have you ever figured out a solution? I am getting the same answer from my Synology SSO server using OIDC service:
{ "detail": "You do not have permission to access this resource. Please contact your administrator for assistance." }I set the following scopes according to the specifications of the server. Everything else including the default scopes would give me an internal server error.
- OAUTH_SCOPES=openid email usernameedit: silly me, I forgot to add the environment variable to enable oauth, and it works now:
ENABLE_OAUTH_SIGNUP=true@utilitee commented on GitHub (Aug 31, 2024):
In my case (Openwebui+Nginx Proxy Manager+Oauth2-proxy) I just use Advance host config
logic is if user requested to ai.mydomain.com/auth then redirect to ai.mydomain.com/oauth2/sign_out. working fine didn't see issue yet. let me know if you got better one.
@luochen1990 commented on GitHub (Sep 3, 2024):
For me, user have to clear cache after successfully register and before first login, otherwise the web page will keep refresh, still not knowing why
@emgitadm commented on GitHub (Oct 4, 2024):
@emgitadm commented on GitHub (Oct 4, 2024):
Where and how can I set the variables? my setup is using docker hosted on a virtual machine (local machine and Authentik?
@dongsupkim-onepredict commented on GitHub (Oct 6, 2024):
@emgitadm with environment variable
@nwithan8 commented on GitHub (Oct 14, 2024):
Can you elaborate on this? Running into the same issue. Do I need to do something at the proxy level (HAProxy running on pfSense)? I haven't had to do that for other apps using Authentik for OIDC all going out the main pipe (external domains rather than internal IPs)
@alimaskin commented on GitHub (Nov 12, 2024):
Hi @christiangierschner, were you able to achieve the desired result with the automatic redirect to Keycloak when opening the Open WebUI URL? Thank you!"
@phyzical commented on GitHub (Dec 11, 2024):
I was wondering this too, that last thing missing is an "auto login"/ "auto redirect" to auto trigger the OIDC flow
@christiangierschner commented on GitHub (Jan 6, 2025):
Hi, Unfortunately not. Our Users have to click on the login button...would love this though...
@voc0der commented on GitHub (Jan 16, 2025):
Same here
@atnjqt commented on GitHub (Jan 16, 2025):
@phyzical & @christiangierschner I've gotten around this auto-login functionality with implementing a passive Shibboleth & Apache reverse proxy setup.
For all routes besides
/auth(and also the/faviconwhich was throwing some strange CORS errors in browser console) this is setup passively.A new user hits my app, the app seemingly redirects the frontend to
/auth_ but this isn't actually a 301 or 302 redirection to the backend proxy.Thus the user needs to refresh the page on
/authone time, which then hits the proxy as my only active shibboleth route, which initiates the call to the IDP which then returns the necessary RequestHeaders I'm mapping to env vars for authorized email domains. I imagine the OIDC flow is similar to a Shibboleth setup!Really if the app did a proper redirect to that
/authroute, instead of just updating the client-side browser URL to have this, it'd work like a login!Here is a sample of that apache config:
@arunbugkiller commented on GitHub (Feb 14, 2025):
I think you would be able to solve most of the problems with below environment variables. Please do try it out
-e ENABLE_OAUTH_SIGNUP=true -e WEBUI_SESSION_COOKIE_SAME_SITE=lax -e WEBUI_AUTH_COOKIE_SAME_SITE=lax -e ENABLE_LOGIN_FORM=True -e OAUTH_MERGE_ACCOUNTS_BY_EMAIL=true