fix(mcp): persist DCR client_id from on-create MCP OAuth Authorize & Fetch

[tin-berri]

Relevant issues

Linear ticket

LIT-4154 https://linear.app/litellm-ai/issue/LIT-4154

This is the stacked follow-up to #31912. It covers variant 2 (on-create "Authorize and Fetch"); #31912 covered variant 1 (post-create authorize).

Pre-Submission checklist

• I have added meaningful tests
• My PR passes all CI/CD checks (e.g., lint, format, unit tests)
• My PR's scope is as isolated as possible; it only solves 1 specific problem
• I have requested a Greptile review by commenting @greptileai and received a Confidence Score of at least 4/5 before requesting a maintainer review

Screenshots / Proof of Fix

The "Authorize and Fetch" button on the create form runs OAuth Dynamic Client Registration (RFC 7591) against a temporary in-memory server that has no DB row, then creates the real server afterward. #31912 persists the DCR client_id when authorize runs against a server that already has a DB row, but on-create there is no row yet, so the minted client_id was dropped and the created server could not refresh (its row had credentials={} and token_url null, and the refresh_token grant 401d at the upstream token endpoint).

The UI already holds the DCR client_id (and client_secret when the upstream returns one) from the register step; it was just discarded at onTokenReceived. This change carries it into form.credentials, so it rides the existing settable credentials.client_id field into the create request, and the backend persists it through the same encrypt_credentials path it already uses for manually-entered OAuth clients. token_url is not carried because it is re-discovered on load (RFC 9728 then 8414); token_endpoint_auth_method is not needed because this flow only ever registers as client_secret_post or none, never client_secret_basic.

Backend already persists a create-supplied client_id encrypted (existing behavior, confirming the mechanism this fix feeds):

$ curl -sX POST localhost:4000/v1/mcp/server -H "Authorization: Bearer $KEY" \
    -d '{"server_name":"proof","url":"https://mcp.linear.app/mcp","transport":"http","auth_type":"oauth2","credentials":{"client_id":"proof-dcr-client-xyz"}}'
# server row: has_client_id=t, stored value is encrypted (kBG8OpnL_uk1... != the plaintext sent)

Live UI before/after (Authorize and Fetch on create, real upstream MCP OAuth, same proxy + Postgres):

BEFORE (server added through the pre-fix build): row credentials={}, token_url null
  $ curl -s "localhost:4000/mcp-rest/tools/list?server_id=<old>" -H "Authorization: Bearer $KEY"
    {"tools": [], "message": "Successfully retrieved tools"}          # 0 tools
  log: refresh_user_oauth_token: refresh request failed ... 401 Unauthorized ... https://<upstream>/token

AFTER (server added through the fixed "Authorize and Fetch"): credentials jsonb has an encrypted client_id
  # expire the stored token, then list tools
  $ curl -s "localhost:4000/mcp-rest/tools/list?server_id=<new>" -H "Authorization: Bearer $KEY"
    {"tools": [ ...18 tools... ], "message": "Successfully retrieved tools"}   # 18 tools
  # the refresh rotated the token: stored expires_at moved from the forced-past value to a fresh future one

Type

Bug Fix

Changes

useMcpOAuthFlow already captures the DCR client_id and client_secret from the register response into its flow state and uses them for authorize and token exchange, but it passed only the token to the onTokenReceived callback. This forwards the registered client to onTokenReceived, and the create form writes client_id (and client_secret when present) into form.credentials alongside the tokens, so the create request carries them and the backend persists them. No backend change is needed; the create path already encrypts and stores credentials.client_id.

A regression test in useMcpOAuthFlow.test.tsx asserts the hook forwards the registered client_id / client_secret to onTokenReceived; it fails on the pre-fix code (callback received only the token) and passes with the fix.

It also flips hasPreconfiguredCredentials from requiring both client_id and client_secret to requiring just client_id, so the UI skips re-registration when a client already exists (a public client has a client_id but no secret). This matches the backend reuse guard in the base PR; together they give one client per server reused across users, rather than re-minting per authorize.

---

Note

Medium Risk
Touches OAuth credential persistence and invalidation in the dashboard; mistakes could leak wrong clients or break refresh, but scope is UI-only with added regression tests and no backend changes.

Overview
Fixes on-create “Authorize & Fetch” so Dynamic Client Registration client_id / client_secret are not dropped before the server is created. useMcpOAuthFlow now passes the registered client into onTokenReceived, treats a preconfigured client_id alone as enough to skip re-registration (public clients), and uses a reset version so a late token exchange cannot repopulate credentials after reset().

The create MCP server form merges those values into form.credentials, records which URL/spec was authorized, and clears OAuth state (credentials, discovered endpoints, tools, flow reset) when MCP URL or OpenAPI spec_path changes after authorization so stale DCR clients are not submitted.

Tests cover hook forwarding, in-flight exchange after reset, DCR reuse vs fresh registration, and URL/spec invalidation on create.

^{Reviewed by Cursor Bugbot for commit d059a91. Bugbot is set up for automated code reviews on this repo. Configure here.}

[tin-berri]

@greptileai

[greptile-apps]

Greptile Summary

This PR fixes on-create "Authorize & Fetch" so that DCR client_id/client_secret minted during OAuth registration are no longer dropped before the MCP server row is created. useMcpOAuthFlow now forwards the registered client to onTokenReceived, and the create form writes those values into form.credentials so they ride the existing create-request path into the backend's encrypt_credentials store.

• useMcpOAuthFlow gains a resetVersionRef that prevents a stale in-flight token exchange from calling onTokenReceived after reset(), and the hasPreconfiguredCredentials guard is relaxed from requiring both client_id + client_secret to just client_id, correctly handling public PKCE clients.
• create_mcp_server.tsx introduces authorizedUrl state and clearAuthorizedOAuthState; together they invalidate stored DCR credentials (and reset the OAuth flow) when the MCP URL, OpenAPI spec path, or transport type changes after an authorization, preventing stale clients from being persisted for a different server endpoint.
• New regression tests cover: hook forwarding of registeredClient, in-flight-exchange-after-reset guard, DCR reuse vs fresh registration, and URL/spec/transport invalidation on the create form.

Confidence Score: 5/5

UI-only change with no backend modifications; DCR credentials are forwarded through an existing encrypted-credentials path already verified in production.

The fix is narrow and well-contained: it threads DCR client data through the callback signature and records which URL was authorized, both backed by new regression tests that fail on the pre-fix code. The reset-version guard correctly prevents stale token exchanges from updating state after reset. No new data is exposed that wasn't already handled by the backend's encrypt_credentials path.

No files require special attention.

Important Files Changed

Filename	Overview
ui/litellm-dashboard/src/hooks/useMcpOAuthFlow.tsx	Adds resetVersionRef for in-flight-exchange cancellation, relaxes hasPreconfiguredCredentials to client_id-only, and forwards {clientId, clientSecret} from stored flow state to onTokenReceived. Logic is correct and consistent with RFC 7591 public-client semantics.
ui/litellm-dashboard/src/components/mcp_tools/create_mcp_server.tsx	Introduces authorizedUrl state and clearAuthorizedOAuthState helper; onTokenReceived now merges DCR client credentials into form fields and records the authorized URL; URL/spec/transport changes trigger invalidation. No backend changes required.
ui/litellm-dashboard/src/hooks/useMcpOAuthFlow.test.tsx	Adds tests for: hook forwarding of DCR client to callback, in-flight exchange ignored after reset, DCR reuse with existing client_id, fresh registration without client_id. Updated assertions match corrected behavior.
ui/litellm-dashboard/src/components/mcp_tools/create_mcp_server.test.tsx	Adds tests for URL/spec_path/transport invalidation of authorized OAuth state on the create form; mock type signatures updated to reflect the new two-argument onTokenReceived contract.

_{Reviews (7): Last reviewed commit: "Merge branch 'litellm_internal_staging' ..." | Re-trigger Greptile}

[codecov]

Codecov Report

✅ All modified and coverable lines are covered by tests.

📢 Thoughts on this report? Let us know!

[tin-berri]

@greptileai

[tin-berri]

@greptileai re-review please (rebased onto the updated base branch).

[tin-berri]

bugbot run

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 1 potential issue.

Autofix Details

Bugbot Autofix prepared a fix for the issue found in the latest run.

• ✅ Fixed: Stale client_id skips registration
  • Cleared fetched OAuth credentials and reset OAuth state when the create form server URL changes, preventing stale DCR client IDs from being reused or saved for a new endpoint.

_{You can send follow-ups to the cloud agent here.}

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.
1 out of 2 committers have signed the CLA.

✅ tin-berri
❌ cursoragent
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[tin-berri]

bugbot run

[tin-berri]

@greptileai rereview

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

Autofix Details

Bugbot Autofix prepared fixes for both issues found in the latest run.

• ✅ Fixed: OpenAPI spec change skips invalidation
  • OAuth authorization now tracks the transport-specific target and clears credentials when an OpenAPI spec URL changes.
• ✅ Fixed: Late OAuth repopulates cleared credentials
  • OAuth reset now invalidates in-flight exchanges so late token responses cannot repopulate cleared credentials.

_{You can send follow-ups to the cloud agent here.}

[mateo-berri]

@greptileai

[mateo-berri]

bugbot run

[cursor]

Cursor Bugbot has reviewed your changes using high effort and found 2 potential issues.

Bugbot Autofix prepared fixes for both issues found in the latest run.

• ✅ Fixed: OAuth survives transport switch
  • OAuth credentials, DCR client data, tokens, tools, and the authorization target are now cleared when transport changes after authorization.
• ✅ Fixed: authorizedUrl survives modal close
  • The modal-close cleanup now clears the stored authorized URL along with the rest of the OAuth state.

_{You can send follow-ups to the cloud agent here.}

^{Reviewed by Cursor Bugbot for commit d059a91. Configure here.}

[tin-berri]

@greptileai

[mateo-berri]

LGTM; thanks!