[GH-ISSUE #23963] feat: Support configurable API Key header name (e.g., OPEN_WEBUI_API_KEY_HEADER) #58796

New Issue

GiteaMirror · 2026-05-05T23:59:04-05:00

GiteaMirror commented

2026-05-05 23:59:04 -05:00

Originally created by @therealslimjp on GitHub (Apr 21, 2026).
Original GitHub issue: https://github.com/open-webui/open-webui/issues/23963

Check Existing Issues

I have searched for all existing open AND closed issues and discussions for similar requests. I have found none that is comparable to my request.

Verify Feature Scope

I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions.

Problem Description

Currently, AuthTokenMiddleware follows a strict priority sequence when authenticating requests:

Authorization: Bearer ... header
Session Cookies
x-api-key header

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:

File: backend/open_webui/utils/asgi_middleware.py:
Logic:
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

Originally created by @therealslimjp on GitHub (Apr 21, 2026). Original GitHub issue: https://github.com/open-webui/open-webui/issues/23963 ### Check Existing Issues - [x] I have searched for all existing **open AND closed** issues and discussions for similar requests. I have found none that is comparable to my request. ### Verify Feature Scope - [x] I have read through and understood the scope definition for feature requests in the Issues section. I believe my feature request meets the definition and belongs in the Issues section instead of the Discussions. ### Problem Description Currently, AuthTokenMiddleware follows a strict priority sequence when authenticating requests: 1. Authorization: Bearer ... header 2. Session Cookies 3. x-api-key header 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 <proxy-token> 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: - File: backend/open_webui/utils/asgi_middleware.py: - Logic: ` 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](https://github.com/open-webui/open-webui/discussions/23915)

GiteaMirror closed this issue

2026-05-05 23:59:05 -05:00

GiteaMirror commented

2026-05-05 23:59:06 -05:00

@tjbck commented on GitHub (Apr 24, 2026):

Addressed in dev.

@tjbck commented on GitHub (Apr 24, 2026): Addressed in dev.

GiteaMirror commented

2026-05-05 23:59:08 -05:00

@therealslimjp commented on GitHub (Apr 27, 2026):

@tjbck after looking at the code in dev, i see that you added the retrieval step for the new env CUSTOM_API_KEY_HEADER, but i still think this would fail if both (Bearer token for the proxy, and CUSTOM_API_KEY_HEADER for openwebui) are set, since AuthTokenMiddleware would still look for the Authorization header first and only checks CUSTOM_API_KEY_HEADER if Auth Header is not set.

i might be missing something here tho, was just a quick review

@therealslimjp commented on GitHub (Apr 27, 2026): @tjbck after looking at the code in dev, i see that you added the retrieval step for the new env CUSTOM_API_KEY_HEADER, but i still think this would fail if both (Bearer token for the proxy, and CUSTOM_API_KEY_HEADER for openwebui) are set, since AuthTokenMiddleware would still look for the Authorization header first and only checks CUSTOM_API_KEY_HEADER if Auth Header is not set. i might be missing something here tho, was just a quick review

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: github-starred/open-webui#58796