Wire in-process JWKS key resolution for vMCP embedded auth server#4526
Merged
tgrunnagle merged 2 commits intomainfrom Apr 3, 2026
Merged
Wire in-process JWKS key resolution for vMCP embedded auth server#4526tgrunnagle merged 2 commits intomainfrom
tgrunnagle merged 2 commits intomainfrom
Conversation
Address code review feedback on incoming_keyprovider_test.go: - MEDIUM: Split TestNewOIDCAuthMiddleware_KeyProviderWiring into two independent top-level functions so each test is fully self-contained; outer-level setup no longer leaks into subtests that don't use it - LOW: Add TestNewOIDCAuthMiddleware_KeyProvider_KidMissFallback to cover the end-to-end kid-miss path at the factory level, confirming the validator falls back to HTTP JWKS when the local provider holds no matching key Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## main #4526 +/- ##
==========================================
- Coverage 69.13% 69.04% -0.10%
==========================================
Files 502 505 +3
Lines 51959 52148 +189
==========================================
+ Hits 35921 36004 +83
- Misses 13254 13360 +106
Partials 2784 2784 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
jerm-dro
approved these changes
Apr 3, 2026
4 tasks
MatteoManzoni
pushed a commit
to DocPlanner/toolhive
that referenced
this pull request
Apr 4, 2026
…acklok#4526) When the embedded auth server is active in vMCP (VirtualMCPServer), token validation was failing silently because the OIDC middleware fetched JWKS keys over HTTP from the proxy's own endpoint — a self-referential HTTP round-trip that required operators to set `insecureAllowHTTP` and/or `jwksAllowPrivateIP` just to make token validation work. These are insecure workarounds, and the failures were difficult to diagnose. This PR extends the fix for the runner and proxy runner to vMCP. The embedded auth server's `KeyProvider` is now extracted in `runServe` and passed through to the OIDC middleware factory, where it is wired into the `TokenValidator` for in-process key resolution. HTTP JWKS fetch is retained as a fallback for key-ID misses and external OIDC providers.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When the embedded auth server is active in vMCP (VirtualMCPServer), token validation was failing silently because the OIDC middleware fetched JWKS keys over HTTP from the proxy's own endpoint — a self-referential HTTP round-trip that required operators to set
insecureAllowHTTPand/orjwksAllowPrivateIPjust to make token validation work. These are insecure workarounds, and the failures were difficult to diagnose.This PR extends the fix from #4502 (which addressed the same problem for the runner and proxy runner) to vMCP. The embedded auth server's
KeyProvideris now extracted inrunServeand passed through to the OIDC middleware factory, where it is wired into theTokenValidatorfor in-process key resolution. HTTP JWKS fetch is retained as a fallback for key-ID misses and external OIDC providers.Closes #4466
Type of change
Test plan
task test)task lint-fix)Changes
cmd/vmcp/app/commands.gokeyProviderfromembeddedAuthServerinrunServeand pass it toNewIncomingAuthMiddlewarepkg/vmcp/auth/factory/incoming.gokeyProvider keys.PublicKeyProviderparameter inNewIncomingAuthMiddlewareandnewOIDCAuthMiddleware; wire it intoauth.WithKeyProvideroption when non-nilpkg/vmcp/auth/factory/incoming_keyprovider_test.gopkg/vmcp/auth/factory/incoming_test.gonilfor the newkeyProviderparameterpkg/vmcp/auth/factory/incoming_upstream_test.gonilfor the newkeyProviderparameterpkg/vmcp/auth/factory/authz_not_wired_test.gonilfor the newkeyProviderparameterDoes this introduce a user-facing change?
Yes. VirtualMCPServer operators using the embedded auth server no longer need to configure
jwksUrl,insecureAllowHTTP, orjwksAllowPrivateIPfor token validation to function. The embedded auth server's signing keys are resolved in-process automatically.Special notes for reviewers
keyProviderparameter isnil-safe throughout: whennil, the OIDC middleware behaves identically to before this change, falling back to HTTP JWKS as the only key source.incoming_keyprovider_test.gostand up a real (in-process) OIDC discovery server to validate the full middleware wiring — local resolution, nil-provider HTTP fallback, and kid-miss HTTP fallback.TokenValidatorin-process resolution logic (includinggetKeyFromLocalProvider) lives inpkg/auth/token.goand was introduced in Resolve JWKS keys in-process for embedded auth server (MCP server) #4502. This PR only adds the vMCP-layer wiring.Generated with Claude Code