mirror of
https://github.com/open-webui/open-webui.git
synced 2026-05-06 10:58:17 -05:00
[GH-ISSUE #23963] feat: Support configurable API Key header name (e.g., OPEN_WEBUI_API_KEY_HEADER) #35659
Reference in New Issue
Block a user
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?
Originally created by @therealslimjp on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23963
Check Existing Issues
Verify Feature Scope
Problem Description
Currently, AuthTokenMiddleware follows a strict priority sequence when authenticating requests:
In deployments where Open WebUI sits behind a Reverse Proxy or API Gateway that requires its own authentication, a conflict occurs. The proxy often requires an Authorization: Bearer token to allow the request through. When this request reaches Open WebUI, the middleware attempts to validate the proxy's token against the internal database. When it fails, it returns a 401 Unauthorized and never reaches the fallback logic for the x-api-key.
This makes it impossible to use the API endpoints through a secure proxy without stripping headers.
Desired Solution you'd like
Introduce an environment variable (e.g., CUSTOM_API_KEY_HEADER) that allows administrators to define a unique header for Open WebUI authentication.
Example Scenario:
Proxy Auth: Uses Authorization: Bearer
Open WebUI Auth: Uses X-OpenWebUI-Key: sk-xxx
If CUSTOM_API_KEY_HEADER is set to X-OpenWebUI-Key, the middleware should check this custom header before or in lieu of the standard Authorization header to avoid the 401 short-circuit.
Technical Details
backend/open_webui/utils/asgi_middleware.py:
custom_header_name = os.getenv("CUSTOM_API_KEY_HEADER", "x-api-key") token = request.headers.get(custom_header_name)This would allow users to bypass the Authorization header conflict entirely by using a dedicated header string that won't be intercepted or misidentified by upstream services.
Alternatives Considered
No response
Additional Context
See Discussion #23915
@tjbck commented on GitHub (Apr 24, 2026):
Addressed in dev.