MCP-Server Per-User Authentication with cost tracking

[almajo]

I have the following target setup:

• OpenWebUI (400 users)
• LiteLLM Proxy
• MCP servers that work with oauth, like Microsoft 365 where the mcp server accesses the user's resources

As some of our MCP servers that we use have a cost-per-call (like Microsoft Dataverse or Copilot RAG API), we would love to track that cost in LiteLLM by adding it as a Litelllm MCP server.

However, I have not found the right settings of how authentication flows from OpenWebUI through the litellm-proxy to the target-mcp and we can still track the tool-calling-costs.

Has anybody managed to implement this in such a setting? After all it's the main use case with mcp servers, where multiple users call the same MCP server in their name.

Really happy to hear back for this. I'm currently on litellm version 1.88.1

[Gloria72]

I would break this into three separate pieces: identity propagation, upstream MCP auth, and MCP tool-call cost accounting.

1. Make sure LiteLLM can identify the end user

For per-user MCP auth to work, the LiteLLM key/session needs a stable user identity. In practice, make sure OpenWebUI is not calling LiteLLM as one anonymous/shared service key only. You want the request/key context to include a real user_id / end-user identity, because the MCP per-user credential endpoints store credentials by (user_id, server_id).

2. Use per-user OAuth for upstream MCP, not one shared credential

Recent LiteLLM code has support for per-user MCP OAuth credential storage and status endpoints, for example endpoints like:

POST   /mcp/server/{server_id}/oauth-user-credential
GET    /mcp/server/{server_id}/oauth-user-credential/status
GET    /mcp/user-credentials
DELETE /mcp/server/{server_id}/oauth-user-credential

The MCP server table/model also has fields such as oauth2_flow, delegate_auth_to_upstream, and oauth_passthrough. So the shape I would aim for is:

• register the MCP server with auth_type: oauth2
• use oauth2_flow: authorization_code for user-delegated access
• store/check each user's OAuth credential for that MCP server
• only expose that MCP server/toolset to keys/users that should be allowed to call it

Since you are on 1.88.1, I would first check whether your build/database has the newer MCP OAuth migrations/fields. The repo has migrations adding delegate_auth_to_upstream, oauth_passthrough, and OAuth2 flow pieces in the 2026-05/2026-06 range. If those fields/endpoints are missing in your install, upgrade before trying to wire this up.

3. Cost tracking exists, but only if you provide a cost model

LiteLLM has an MCP cost calculator path for tool calls. From the current code, MCP cost defaults to 0.0 unless the MCP tool metadata has cost info. The supported shape is roughly:

{
  "default_cost_per_query": 0.01,
  "tool_name_to_cost_per_query": {
    "dataverse_search": 0.02,
    "copilot_rag_query": 0.05
  }
}

That means LiteLLM can track a fixed per-call cost per MCP server/tool. If Microsoft Dataverse/Copilot returns dynamic usage-based cost, you will likely need a hook after the MCP tool call to set response_cost from the upstream response/metadata; the cost calculator checks model_call_details["response_cost"] first, then falls back to the static MCP cost info.

Suggested minimal test

1. Upgrade to a LiteLLM version that has the MCP OAuth/user credential endpoints.
2. Register one MCP server with OAuth2 authorization-code flow.
3. Create two LiteLLM users/keys and connect only user A's OAuth credential for the MCP server.
4. Confirm user A can list/call the MCP tool and user B gets an auth challenge/denial.
5. Add a static default_cost_per_query for that MCP server/tool.
6. Make one tool call and check LiteLLM spend/logging for the user/key/team.

So: yes, the architecture you want is the right direction, but I would not expect it to be just header forwarding from OpenWebUI. Treat LiteLLM as the identity + credential broker: stable end-user identity in, per-user OAuth credential stored for the MCP server, then fixed or hook-derived MCP tool cost attached to the tool call.

[CedricConday]

@Gloria72's three-way split is right; here's how it maps onto LiteLLM specifically:

1. Identity propagation — the OpenWebUI user must reach the proxy as a LiteLLM virtual key/user (per-user key, or the user field / litellm_metadata). No attribution without this.
2. Upstream MCP OAuth — LiteLLM's MCP gateway forwards to the target server, but the M365/Dataverse token is per-end-user, not one service credential. LiteLLM won't broker the user's OAuth for you — the token has to be injected per request (header passthrough on the MCP server config), so your gateway/OpenWebUI holds the user token and passes it down. That handoff is the part with no built-in.
3. Cost accounting — the real gap: MCP tool calls aren't token-priced, so token-based cost tracking misses them. Attach cost via a custom callback that, per tool invocation, looks up a per-call price and writes a spend record against that user's key. Token spend and tool-call spend are two ledgers you sum per user.

Happy to go deeper on the callback shape — I've worked in litellm's codebase. Short version: don't expect built-in per-user OAuth brokering or per-call MCP pricing; plan for token passthrough + a custom cost callback.

[arpitraval]

For this setup, I would separate three identities instead of trying to solve everything with one credential:

1. End-user identity from OpenWebUI
2. LiteLLM proxy identity / API key
3. Upstream MCP OAuth identity

For 400 users, I would avoid one shared OAuth credential for the MCP server if the MCP server accesses user-owned resources such as Microsoft 365.

A safer production pattern is:

OpenWebUI user
  -> LiteLLM proxy request with stable user/team metadata
  -> per-user MCP OAuth credential lookup
  -> MCP tool call with user-scoped OAuth token
  -> LiteLLM logging/callback/cost tracking by user/team/tool

The important separation is:

• provider/service credential: used by LiteLLM/proxy infrastructure
• end-user identity: used for audit, cost attribution, and authorization
• MCP OAuth token: used to access the user’s upstream resources
• request metadata: used for logs, spend tracking, and debugging

For cost tracking, I would attach stable metadata to every request/tool call:

{
  "user_id": "user_123",
  "team_id": "team_abc",
  "mcp_server": "microsoft365",
  "tool_name": "search_mail",
  "request_id": "req_123"
}

Then cost can be attributed at the LiteLLM layer even if the upstream MCP server has its own OAuth flow.

If LiteLLM’s current MCP OAuth credential endpoints are available in your version, I would first check whether the user credential is being stored and retrieved per server_id and per user, rather than globally.

The main thing to verify is that the OAuth token is used for subsequent MCP tool calls, not only during the initial connection flow.

[Ganesh-403]

@almajo
Yes, this architecture is supported, but there are a few pieces that need to be separated:

1. End-user identity (for attribution and cost tracking)
2. Per-user OAuth credentials (for the upstream MCP server)
3. Tool call cost tracking

LiteLLM has built-in MCP APIs for managing per-user credentials, including OAuth-backed servers:

• POST /v1/mcp/server/{server_id}/oauth-user-credential
• GET /v1/mcp/server/{server_id}/oauth-user-credential/status
• GET /v1/mcp/user-credentials
• DELETE /v1/mcp/server/{server_id}/oauth-user-credential

These APIs are designed to associate credentials with a specific user and MCP server, rather than using one shared credential for everyone. :contentReference[oaicite:0]{index=0}

For your setup, I'd recommend:

OpenWebUI
      │
      ▼
LiteLLM Proxy
      │
      ├── identifies the end user (user_id / virtual key)
      ├── looks up that user's OAuth credential for the MCP server
      ├── invokes the MCP tool using that user's OAuth token
      └── records the MCP tool call against that same user

This gives you:

• per-user Microsoft 365 / Dataverse authorization
• per-user usage attribution
• centralized logging and governance

Regarding cost tracking, LiteLLM's MCP gateway supports assigning costs to MCP tool calls, but those costs aren't inferred automatically from third-party services. If your upstream service has a fixed per-call price (e.g. Dataverse API calls), you can configure that. If the service returns dynamic billing information, you'd likely need to capture that in a callback or custom integration and attach it to the request before logging. :contentReference[oaicite:1]{index=1}

One thing I'd check is your LiteLLM version. You mentioned 1.88.1—the MCP OAuth APIs and user-credential endpoints are present in the current API surface, so if you don't see those endpoints in your deployment, upgrading would be worthwhile before investing much effort in the integration. :contentReference[oaicite:2]{index=2}

A couple of questions that would help narrow down the best approach:

• Are you using LiteLLM's MCP Gateway, or are you forwarding MCP requests through custom routes?
• Do you want LiteLLM to perform the OAuth flow and store the credentials, or does OpenWebUI already obtain the Microsoft OAuth token and you simply want LiteLLM to use it for downstream MCP calls?

The answer changes slightly depending on who owns the OAuth lifecycle.

If this solves your problem, feel free to mark it as the accepted answer so others can find it easily.

[vgmartinez]

Disclosure: TrustGate / NeuralTrust DevRel.

For Open WebUI (N users) → gateway → OAuth MCP servers with per-call cost, the hard part is keeping one user identity all the way through — not just proxying tools.

Patterns that usually work:

1. Don't share one service account for all users. If Dataverse/Copilot see a single gateway identity, you lose both authz and cost attribution. Prefer token-exchange / OBO (or per-user OAuth tokens stored keyed by Open WebUI user id) so upstream calls are on behalf of the human.
2. Put cost on the gateway hop that already knows the consumer. Emit a usage event per tools/call (user/tenant id, tool name, upstream request id, units). Even if the MCP server bills differently, you need that join key or LiteLLM spend will never line up with vendor invoices.
3. Filter tools/list per user/role. Otherwise every user sees every expensive tool and you fight blast radius in the UI instead of at the control plane.
4. Open WebUI → gateway auth: give each Open WebUI user (or group) a distinct virtual key / consumer credential into the gateway; map that to the OAuth token store. The MCP OAuth client stays on the gateway, not in every browser session.

LiteLLM's MCP proxy is a reasonable place to host (2)+(4) if you're already standardized on it. If you outgrow LLM-only tenancy and want the same consumers/audit across chat completions and MCP, that's the Agent Gateway shape we work on with TrustGate (Go, Apache-2.0): https://github.com/NeuralTrust/TrustGate — either way, fix identity propagation before tuning cost dashboards.

[paramjeetn]

In LiteLLM with OpenWebUI for multi-tenant MCP tool routing and user-specific cost tracking:

1. Pass-Through End-User Identity:
   In OpenWebUI, ensure user tokens or user identifiers are forwarded in the request header (e.g. user: "user-123" or Authorization: Bearer <user_jwt>).

2. LiteLLM Config Mapping:
   In your config.yaml, configure the MCP server under litellm_params and enable forward_headers:

model_list:
  - model_name: mcp-tool-router
    litellm_params:
      model: mcp/copilot-rag
      api_base: https://your-mcp-service.internal
      forward_headers: ["Authorization", "X-User-Id"]

general_settings:
  track_user_cost: true

3. Per-User Budgeting / Tracking:
   When requests arrive with user specified in the body or header, LiteLLM associates the tool invocation latency and cost directly to that specific user ID in the LiteLLM PostgreSQL database (LiteLLM_UserTable).