github-starred/open-webui
2
0
Fork 0
mirror of https://github.com/open-webui/open-webui.git synced 2026-03-10 07:43:10 -05:00
Code Issues 308 Packages Projects Releases 100 Wiki Activity

issue: Support internal authentication URL for OAUTH in Open WebUI #5710

New Issue
Open
opened 2025-11-11 16:30:55 -06:00 by GiteaMirror · 0 comments
GiteaMirror commented 2025-11-11 16:30:55 -06:00
Owner
Copy Link

Originally created by @studyfranco on GitHub (Jul 6, 2025).

Originally assigned to: @tjbck on GitHub.

Check Existing Issues

  • I have searched the existing issues and discussions.
  • I am using the latest version of Open WebUI.

Installation Method

Docker

Open WebUI Version

v0.6.15

Ollama Version (if applicable)

No response

Operating System

Debian 13

Browser (if applicable)

No response

Confirmation

  • I have read and followed all instructions in README.md.
  • I am using the latest version of both Open WebUI and Ollama.
  • I have included the browser console logs.
  • I have included the Docker container logs.
  • I have provided every relevant configuration, setting, and environment variable used in my setup.
  • I have clearly listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc).
  • I have documented step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation. My steps:
  • Start with the initial platform/version/OS and dependencies used,
  • Specify exact install/launch/configure commands,
  • List URLs visited, user input (incl. example values/emails/passwords if needed),
  • Describe all options and toggles enabled or changed,
  • Include any files or environmental changes,
  • Identify the expected and actual result at each stage,
  • Ensure any reasonably skilled user can follow and hit the same issue.

Expected Behavior

Open WebUI should allow operators to configure separate “public” and “internal” URLs for the OAuth/OIDC provider. In a locked‑down environment where outbound traffic is restricted by iptables or firewall rules, the backend would use the internally reachable endpoint for:
Fetching the OIDC discovery document (.well-known/openid-configuration)
Performing token exchanges
Constructing authorization and callback redirects
Meanwhile, clients (browsers) would continue to use the public URL for end‑user interactions. This split‑URL approach mirrors solutions like Apache Guacamole’s OPENID_JWKS_ENDPOINT vs. OPENID_ISSUER.

Actual Behavior

When a user navigates to /oauth/oidc/callback, Open WebUI attempts to fetch metadata from the public-facing OIDC endpoint. Because the container cannot reach that URL (egress is blocked), the HTTP request to retrieve .well-known/openid-configuration times out (httpx.ConnectTimeout) and the request fails with a 500 Internal Server Error.

Steps to Reproduce

  1. Deploy Open WebUI and an OIDC provider (e.g., Authentik) in the same Docker network
  2. Configure Traefik (or another reverse proxy) to expose the OIDC provider on a public hostname (e.g., https://auth.example.com) while forwarding internal requests to the provider container at an internal address (e.g., http://auth-service:9000)
  3. Apply iptables rules to restrict connections from the Open WebUI container to the public internet.
  4. In your Open WebUI .env, set:

OPENID_PROVIDER_URL=https://auth.example.com/application/o/myapp/.well-known/openid-configuration
OPENID_REDIRECT_URI=https://openwebui.example.com/oauth/oidc/callback

  1. Start Open WebUI and attempt to log in.

Logs & Screenshots

auth.log

Additional Information

No response

Originally created by @studyfranco on GitHub (Jul 6, 2025). Originally assigned to: @tjbck on GitHub. ### Check Existing Issues - [x] I have searched the existing issues and discussions. - [x] I am using the latest version of Open WebUI. ### Installation Method Docker ### Open WebUI Version v0.6.15 ### Ollama Version (if applicable) _No response_ ### Operating System Debian 13 ### Browser (if applicable) _No response_ ### Confirmation - [x] I have read and followed all instructions in `README.md`. - [x] I am using the latest version of **both** Open WebUI and Ollama. - [x] I have included the browser console logs. - [x] I have included the Docker container logs. - [x] I have **provided every relevant configuration, setting, and environment variable used in my setup.** - [x] I have clearly **listed every relevant configuration, custom setting, environment variable, and command-line option that influences my setup** (such as Docker Compose overrides, .env values, browser settings, authentication configurations, etc). - [x] I have documented **step-by-step reproduction instructions that are precise, sequential, and leave nothing to interpretation**. My steps: - Start with the initial platform/version/OS and dependencies used, - Specify exact install/launch/configure commands, - List URLs visited, user input (incl. example values/emails/passwords if needed), - Describe all options and toggles enabled or changed, - Include any files or environmental changes, - Identify the expected and actual result at each stage, - Ensure any reasonably skilled user can follow and hit the same issue. ### Expected Behavior Open WebUI should allow operators to configure separate “public” and “internal” URLs for the OAuth/OIDC provider. In a locked‑down environment where outbound traffic is restricted by iptables or firewall rules, the backend would use the internally reachable endpoint for: Fetching the OIDC discovery document (.well-known/openid-configuration) Performing token exchanges Constructing authorization and callback redirects Meanwhile, clients (browsers) would continue to use the public URL for end‑user interactions. This split‑URL approach mirrors solutions like Apache Guacamole’s OPENID_JWKS_ENDPOINT vs. OPENID_ISSUER. ### Actual Behavior When a user navigates to /oauth/oidc/callback, Open WebUI attempts to fetch metadata from the public-facing OIDC endpoint. Because the container cannot reach that URL (egress is blocked), the HTTP request to retrieve .well-known/openid-configuration times out (httpx.ConnectTimeout) and the request fails with a 500 Internal Server Error. ### Steps to Reproduce 1. Deploy Open WebUI and an OIDC provider (e.g., Authentik) in the same Docker network 2. Configure Traefik (or another reverse proxy) to expose the OIDC provider on a public hostname (e.g., https://auth.example.com) while forwarding internal requests to the provider container at an internal address (e.g., http://auth-service:9000) 3. Apply iptables rules to restrict connections from the Open WebUI container to the public internet. 4. In your Open WebUI .env, set: > OPENID_PROVIDER_URL=https://auth.example.com/application/o/myapp/.well-known/openid-configuration > OPENID_REDIRECT_URI=https://openwebui.example.com/oauth/oidc/callback 5. Start Open WebUI and attempt to log in. ### Logs & Screenshots [auth.log](https://github.com/user-attachments/files/21089493/auth.log) ### Additional Information _No response_
GiteaMirror added the bug label 2025-11-11 16:30:55 -06:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
bug
core
documentation
enhancement
good first issue
help wanted
non-core
pull-request
Mirrored from GitHub Pull Request
 python
question
testing wanted
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
GiteaMirror ninjasurge
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github-starred/open-webui#5710
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?