8 views
-/https://github.com/berriai/litellm/issues/28537
GitHub · issue

#28537 [Bug]: JWTAuthManager.auth_builder uses raw JWT user_id, not canonical UserTable.user_id, silently splitting BYOK credentials / spend / team membership across two identities for the same SSO user

  • State: open
  • Author: @justalittleadam
  • Labels: bug, proxy

### Check for existing issues

- [x] I have searched the existing issues and checked that my issue is not a duplicate.

### What happened?

> **Status (2026-05-21):** Verified unfixed in `v1.85.1` (latest stable) and `main` at `HEAD`. The relevant region of `auth_builder` is byte-identical across `v1.83.14-stable`, `v1.83.14-stable.patch.3`, `v1.85.1`, and `main`. No commit in the recent history of `litellm/proxy/auth/handle_jwt.py` touches `user_id` reconciliation. Issue/PR search for `byok_auth_required user_id`, `JWT user_id mismatch sso_user_id`, and `JWT user_id BYOK` returned no hits.

## Symptom

A user provisioned via SSO has a `LiteLLM_UserTable` row with a UUID `user_id` and an `sso_user_id`/`user_email` populated by the SSO callback. They save a BYOK PAT for an MCP server from the dashboard (sk-key auth — uses the canonical UUID). When the same user calls a tool on that MCP server through OpenWebUI (JWT bearer auth — `user_id_jwt_field: "email"`), the proxy returns:

```json { "error": "byok_auth_required", "server_id": "<server-uuid>", "server_name": "mcp_jedai_jira", "message": "No stored credential found for this BYOK server. Complete the OAuth authorization …

GitHub resolver

Import GitHub neighbors on demand. Results are saved as system ingests.

Refresh page
vote history (2 events)
#0 of 0 · 31d17h47m34s ago — entered · #import:https:::github.com:berriai:litellm post #3185
The left requires cross-cutting identity reconciliation, compatibility handling, and regression coverage across authentication and authorization paths; the right is a localized provider-metadata/UI consistency fix.
#0 of 0 · 31d17h47m2s ago — current · #import:https:::github.com:berriai:litellm post #3194
The left issue is harder because it requires isolating a potentially workload-dependent memory regression, profiling background database and cleanup behavior, reproducing it under realistic deployment conditions, and validating a safe fix without introducing operational instability. The right issue is narrower and likely permits a localized identity-reconciliation change with focused authentication, persistence, and authorization tests.
discussed in #import:https:::github.com:berriai:litellm

ranked child groups

no voted pairs yet in this scope

cli
src
spread
search