[GH-ISSUE #483] feat: OAuth/OIDC #27614

New Issue

Closed

opened 2026-04-25 02:20:25 -05:00 by GiteaMirror · 54 comments

GiteaMirror commented 2026-04-25 02:20:25 -05:00

Owner

Copy Link

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

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

GiteaMirror added the enhancementgood first issuehelp wantednon-core labels 2026-04-25 02:20:25 -05:00

GiteaMirror closed this issue 2026-04-25 02:20:26 -05:00

GiteaMirror commented 2026-04-25 02:20:27 -05:00

Author

Owner

Copy Link

@tjbck commented on GitHub (Jan 15, 2024):

Related: #340

<!-- gh-comment-id:1892736967 --> @tjbck commented on GitHub (Jan 15, 2024): Related: #340

GiteaMirror commented 2026-04-25 02:20:28 -05:00

Author

Owner

Copy Link

@mafrasiabi commented on GitHub (Jan 19, 2024):

It would be very good to have integration with AzureAD too.

<!-- gh-comment-id:1900881339 --> @mafrasiabi commented on GitHub (Jan 19, 2024): It would be very good to have integration with AzureAD too.

GiteaMirror commented 2026-04-25 02:20:28 -05:00

Author

Owner

Copy Link

@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-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.

GiteaMirror commented 2026-04-25 02:20:29 -05:00

Author

Owner

Copy Link

@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.

<!-- 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.

GiteaMirror commented 2026-04-25 02:20:30 -05:00

Author

Owner

Copy Link

@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?

<!-- 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?

GiteaMirror commented 2026-04-25 02:20:30 -05:00

Author

Owner

Copy Link

@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.

<!-- 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.

GiteaMirror commented 2026-04-25 02:20:30 -05:00

Author

Owner

Copy Link

@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!

<!-- 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!

GiteaMirror commented 2026-04-25 02:20:31 -05:00

Author

Owner

Copy Link

@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)

<!-- 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)

GiteaMirror commented 2026-04-25 02:20:31 -05:00

Author

Owner

Copy Link

@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, 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

GiteaMirror commented 2026-04-25 02:20:32 -05:00

Author

Owner

Copy Link

@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.

<!-- 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.

GiteaMirror commented 2026-04-25 02:20:33 -05:00

Author

Owner

Copy Link

@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

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: {}

tailscale-serve.json

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

oauth2-proxy

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.

docker-compose.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

oauth2-proxy.cfg

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"

oauth2-proxy.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/

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.

GiteaMirror commented 2026-04-25 02:20:34 -05:00

Author

Owner

Copy Link

@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: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!

GiteaMirror commented 2026-04-25 02:20:34 -05:00

Author

Owner

Copy Link

@Michelklingler commented on GitHub (Apr 3, 2024):

I agree super well done documentation!
Thanks a lot!

<!-- gh-comment-id:2035807506 --> @Michelklingler commented on GitHub (Apr 3, 2024): I agree super well done documentation! Thanks a lot!

GiteaMirror commented 2026-04-25 02:20:35 -05:00

Author

Owner

Copy Link

@cellulosa commented on GitHub (Apr 4, 2024):

any luck setting this up with Authelia?

<!-- gh-comment-id:2036805984 --> @cellulosa commented on GitHub (Apr 4, 2024): any luck setting this up with Authelia?

GiteaMirror commented 2026-04-25 02:20:35 -05:00

Author

Owner

Copy Link

@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/

<!-- 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/

GiteaMirror commented 2026-04-25 02:20:36 -05:00

Author

Owner

Copy Link

@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 !!

GiteaMirror commented 2026-04-25 02:20:37 -05:00

Author

Owner

Copy Link

@sammcj commented on GitHub (Apr 6, 2024):

Confirmed I've got this working with Traefik + Authentik 🎉

services:
  open-webui:
    ...
    environment:
      WEBUI_AUTH_TRUSTED_EMAIL_HEADER: 'X-authentik-email'
    networks:
      - traefik-servicenet
    labels:
      traefik.enable: true
      traefik.http.routers.open-webui.middlewares: authentik
      traefik.http.middlewares.open-webui-auth.headers.customrequestheaders.X-authentik-email: "true"

Large example available here: https://github.com/open-webui/open-webui/issues/929#issuecomment-2041296801

<!-- gh-comment-id:2041216612 --> @sammcj commented on GitHub (Apr 6, 2024): Confirmed I've got this working with Traefik + Authentik 🎉 ```yaml services: open-webui: ... environment: WEBUI_AUTH_TRUSTED_EMAIL_HEADER: 'X-authentik-email' networks: - traefik-servicenet labels: traefik.enable: true traefik.http.routers.open-webui.middlewares: authentik traefik.http.middlewares.open-webui-auth.headers.customrequestheaders.X-authentik-email: "true" ``` Large example available here: https://github.com/open-webui/open-webui/issues/929#issuecomment-2041296801

GiteaMirror commented 2026-04-25 02:20:38 -05:00

Author

Owner

Copy Link

@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:

  open-webui:
    environment:
      - WEBUI_AUTH_TRUSTED_EMAIL_HEADER=Remote-Email

Make sure to pass it in the 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

<!-- 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 ```

GiteaMirror commented 2026-04-25 02:20:39 -05:00

Author

Owner

Copy Link

@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?

<!-- 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?

GiteaMirror commented 2026-04-25 02:20:39 -05:00

Author

Owner

Copy Link

@aitzubi commented on GitHub (Apr 29, 2024):

Anybody knows how to implement this using Keycloak?

<!-- gh-comment-id:2082149425 --> @aitzubi commented on GitHub (Apr 29, 2024): Anybody knows how to implement this using Keycloak?

GiteaMirror commented 2026-04-25 02:20:40 -05:00

Author

Owner

Copy Link

@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

GiteaMirror commented 2026-04-25 02:20:41 -05:00

Author

Owner

Copy Link

@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: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 > ```

GiteaMirror commented 2026-04-25 02:20:42 -05:00

Author

Owner

Copy Link

@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

<!-- 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

GiteaMirror commented 2026-04-25 02:20:43 -05:00

Author

Owner

Copy Link

@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:2101652727 --> @tjbck commented on GitHub (May 8, 2024): @sammcj Just pushed a fix for trusted header support, let me know if the issue persists!

GiteaMirror commented 2026-04-25 02:20:44 -05:00

Author

Owner

Copy Link

@sammcj commented on GitHub (May 8, 2024):

comment moved to https://github.com/open-webui/open-webui/issues/929#issuecomment-2101667151

<!-- 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

GiteaMirror commented 2026-04-25 02:20:45 -05:00

Author

Owner

Copy Link

@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.

GiteaMirror commented 2026-04-25 02:20:46 -05:00

Author

Owner

Copy Link

@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.

<!-- 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.

GiteaMirror commented 2026-04-25 02:20:47 -05:00

Author

Owner

Copy Link

@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

<!-- 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)

GiteaMirror commented 2026-04-25 02:20:48 -05:00

Author

Owner

Copy Link

@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

<!-- 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

GiteaMirror commented 2026-04-25 02:20:50 -05:00

Author

Owner

Copy Link

@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.

<!-- 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.

GiteaMirror commented 2026-04-25 02:20:51 -05:00

Author

Owner

Copy Link

@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?

GiteaMirror commented 2026-04-25 02:20:52 -05:00

Author

Owner

Copy Link

@Louden7 commented on GitHub (Jul 25, 2024):

@christiangierschner check out #4068 as it might satisfy your request.

<!-- gh-comment-id:2249210614 --> @Louden7 commented on GitHub (Jul 25, 2024): @christiangierschner check out #4068 as it might satisfy your request.

GiteaMirror commented 2026-04-25 02:20:53 -05:00

Author

Owner

Copy Link

@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

<!-- 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 ```

GiteaMirror commented 2026-04-25 02:20:54 -05:00

Author

Owner

Copy Link

@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.

<!-- 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.

GiteaMirror commented 2026-04-25 02:20:55 -05:00

Author

Owner

Copy Link

@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!

GiteaMirror commented 2026-04-25 02:20:55 -05:00

Author

Owner

Copy Link

@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

services:
  ollama:
    image: ghcr.io/open-webui/open-webui:v0.3.11
    volumes:
      - ollama-webui:/app/backend/data
    environment:
      OLLAMA_BASE_URL: http://ollama-api:11434
      ENABLE_OAUTH_SIGNUP: true
      ENABLE_LOGIN_FORM: false
      ENABLE_SIGNUP: false
      OAUTH_MERGE_ACCOUNTS_BY_EMAIL: true
      OAUTH_USERNAME_CLAIM: name
      OAUTH_CLIENT_ID: ollama
      OAUTH_CLIENT_SECRET:
      OPENID_PROVIDER_URL: https://$KEYCLOAKURL/auth/realms/$REALMNAME/.well-known/openid-configuration
      OAUTH_PROVIDER_NAME: Keycloak
    extra_hosts:
      - host.docker.internal:host-gateway
    restart: unless-stopped
    networks:
      - backend
      - frontend

    labels:
      - traefik.enable=true
      - traefik.http.routers.ollama.rule=Host(`$HOST_NAME`)
      - traefik.http.routers.ollama.tls.certresolver=internal-acme
      - traefik.http.routers.ollama.service=ollama
      - traefik.http.routers.ollama.entrypoints=https
      - traefik.http.services.ollama.loadbalancer.server.port=8080

<!-- gh-comment-id:2271356564 --> @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 ``` services: ollama: image: ghcr.io/open-webui/open-webui:v0.3.11 volumes: - ollama-webui:/app/backend/data environment: OLLAMA_BASE_URL: http://ollama-api:11434 ENABLE_OAUTH_SIGNUP: true ENABLE_LOGIN_FORM: false ENABLE_SIGNUP: false OAUTH_MERGE_ACCOUNTS_BY_EMAIL: true OAUTH_USERNAME_CLAIM: name OAUTH_CLIENT_ID: ollama OAUTH_CLIENT_SECRET: OPENID_PROVIDER_URL: https://$KEYCLOAKURL/auth/realms/$REALMNAME/.well-known/openid-configuration OAUTH_PROVIDER_NAME: Keycloak extra_hosts: - host.docker.internal:host-gateway restart: unless-stopped networks: - backend - frontend labels: - traefik.enable=true - traefik.http.routers.ollama.rule=Host(`$HOST_NAME`) - traefik.http.routers.ollama.tls.certresolver=internal-acme - traefik.http.routers.ollama.service=ollama - traefik.http.routers.ollama.entrypoints=https - traefik.http.services.ollama.loadbalancer.server.port=8080 ```

GiteaMirror commented 2026-04-25 02:20:56 -05:00

Author

Owner

Copy Link

@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:

<!-- 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: 

GiteaMirror commented 2026-04-25 02:20:57 -05:00

Author

Owner

Copy Link

@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!

<!-- 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!

GiteaMirror commented 2026-04-25 02:20:57 -05:00

Author

Owner

Copy Link

@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)

<!-- 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)

GiteaMirror commented 2026-04-25 02:20:58 -05:00

Author

Owner

Copy Link

@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 ^^;

GiteaMirror commented 2026-04-25 02:20:59 -05:00

Author

Owner

Copy Link

@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.

<!-- 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.

GiteaMirror commented 2026-04-25 02:21:01 -05:00

Author

Owner

Copy Link

@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

<!-- 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`

GiteaMirror commented 2026-04-25 02:21:02 -05:00

Author

Owner

Copy Link

@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.

<!-- 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.

GiteaMirror commented 2026-04-25 02:21:03 -05:00

Author

Owner

Copy Link

@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

<!-- 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

GiteaMirror commented 2026-04-25 02:21:04 -05:00

Author

Owner

Copy Link

@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:

<!-- 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: > > 

GiteaMirror commented 2026-04-25 02:21:05 -05:00

Author

Owner

Copy Link

@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?

<!-- 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?

GiteaMirror commented 2026-04-25 02:21:07 -05:00

Author

Owner

Copy Link

@dongsupkim-onepredict commented on GitHub (Oct 6, 2024):

@emgitadm with environment variable

<!-- gh-comment-id:2395410825 --> @dongsupkim-onepredict commented on GitHub (Oct 6, 2024): @emgitadm with environment variable

GiteaMirror commented 2026-04-25 02:21:07 -05:00

Author

Owner

Copy Link

@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)

<!-- 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)

GiteaMirror commented 2026-04-25 02:21:08 -05:00

Author

Owner

Copy Link

@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!"

<!-- 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!"

GiteaMirror commented 2026-04-25 02:21:08 -05:00

Author

Owner

Copy Link

@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

<!-- 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

GiteaMirror commented 2026-04-25 02:21:09 -05:00

Author

Owner

Copy Link

@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...

GiteaMirror commented 2026-04-25 02:21:10 -05:00

Author

Owner

Copy Link

@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...

<!-- 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...

GiteaMirror commented 2026-04-25 02:21:10 -05:00

Author

Owner

Copy Link

@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: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" ```

GiteaMirror commented 2026-04-25 02:21:11 -05:00

Author

Owner

Copy Link

@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

<!-- 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

Sign in to join this conversation.

No Branch/Tag Specified

Branches Tags

main

dev

v0.9.2

v0.9.1

v0.9.0

v0.8.12

v0.8.11

v0.8.10

v0.8.9

v0.8.8

v0.8.7

v0.8.6

v0.8.5

v0.8.4

v0.8.3

v0.8.2

v0.8.1

v0.8.0

v0.7.2

v0.7.1

v0.7.0

v0.6.43

v0.6.42

v0.6.41

v0.6.40

v0.6.39

v0.6.38

v0.6.37

v0.6.36

v0.6.35

v0.6.34

v0.6.33

v0.6.32

v0.6.31

v0.6.30

v0.6.29

v0.6.28

v0.6.27

v0.6.26

v0.6.25

v0.6.24

v0.6.23

v0.6.22

v0.6.21

v0.6.20

v0.6.19

v0.6.18

v0.6.17

v0.6.16

v0.6.15

v0.6.14

v0.6.13

v0.6.12

v0.6.11

v0.6.10

v0.6.9

v0.6.8

v0.6.7

v0.6.6

v0.6.5

v0.6.4

v0.6.3

v0.6.2

v0.6.1

v0.6.0

v0.5.20

v0.5.19

v0.5.18

v0.5.17

v0.5.16

v0.5.15

v0.5.14

v0.5.13

v0.5.12

v0.5.11

v0.5.10

v0.5.9

v0.5.8

v0.5.7

v0.5.6

v0.5.5

v0.5.4

v0.5.3

v0.5.2

v0.5.1

v0.5.0

v0.4.8

v0.4.7

v0.4.6

v0.4.5

v0.4.4

v0.4.3

v0.4.2

v0.4.1

v0.4.0

v0.3.35

v0.3.34

v0.3.33

v0.3.32

v0.3.31

v0.3.30

v0.3.29

v0.3.28

v0.3.27

v0.3.26

v0.3.25

v0.3.24

v0.3.23

v0.3.22

v0.3.21

v0.3.20

v0.3.19

v0.3.18

v0.3.17

v0.3.16

v0.3.15

v0.3.14

v0.3.13

v0.3.12

v0.3.11

v0.3.10

v0.3.9

v0.3.8

v0.3.7

v0.3.6

v0.3.5

v0.3.4

v0.3.3

v0.3.2

v0.3.1

v0.3.0

v0.2.5

v0.2.4

v0.2.3

v0.2.2

v0.2.1

v0.2.0

v0.1.125

v0.1.124

v0.1.123

v0.1.122

v0.1.121

v0.1.120

v0.1.119

v0.1.118

v0.1.117

v0.1.116

v0.1.115

v0.1.114

v0.1.113

v0.1.112

v0.1.111

v0.1.110

v0.1.109

v0.1.108

v0.1.107

v0.1.106

v0.1.105

v0.1.104

v0.1.103

v0.1.102

Labels

Clear labels

bug

confirmed

confirmed issue

core

documentation

enhancement

good first issue

help wanted

non-core

pull-request

Mirrored from GitHub Pull Request

python

question

testing wanted

No Label enhancement good first issue help wanted non-core

Milestone

No items

No Milestone

Projects

Clear projects

No project

Assignees

Clear assignees

GiteaMirror ninjasurge

No Assignees

1 Participants

Notifications

Subscribe

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#27614