Add OAuth/OIDC authentication for remote MCP server registries#3908
Merged
ChrisJBurns merged 12 commits intomainfrom Mar 11, 2026
Merged
Add OAuth/OIDC authentication for remote MCP server registries#3908ChrisJBurns merged 12 commits intomainfrom
ChrisJBurns merged 12 commits intomainfrom
Conversation
4 tasks
3331d6b to
4ab400e
Compare
Contributor
There was a problem hiding this comment.
Large PR Detected
This PR exceeds 1000 lines of changes and requires justification before it can be reviewed.
How to unblock this PR:
Add a section to your PR description with the following format:
## Large PR Justification
[Explain why this PR must be large, such as:]
- Generated code that cannot be split
- Large refactoring that must be atomic
- Multiple related changes that would break if separated
- Migration or data transformationAlternative:
Consider splitting this PR into smaller, focused changes (< 1000 lines each) for easier review and reduced risk.
See our Contributing Guidelines for more details.
This review will be automatically dismissed once you add the justification section.
rdimitrov
approved these changes
Mar 11, 2026
jhrozek
reviewed
Mar 11, 2026
Contributor
jhrozek
left a comment
There was a problem hiding this comment.
one Johnny-came-late comment inline
| return fmt.Errorf("failed to create oauth2 config: %w", err) | ||
| } | ||
|
|
||
| o.tokenSource = remote.CreateTokenSourceFromCached(oauth2Cfg, refreshToken, o.oauthCfg.CachedTokenExpiry) |
Contributor
There was a problem hiding this comment.
Should the returned token source here be wrapped PersistingTokenSource? The IDP would return a rotated refresh token here. perfromOAuthFlow does that correctly already
3 tasks
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
3 participants
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
Organizations deploying private MCP server registries behind identity providers
(Okta, Azure AD, etc.) need a way to attach credentials to registry API calls.
This implements RFC-0043 Phase 1: browser-based OAuth/OIDC authentication with
PKCE for the ToolHive CLI.
pkg/registry/auth/package withTokenSourceinterface, OAuth tokensource (three-stage: in-memory cache → secrets manager restore → browser flow),
and HTTP transport wrapper for Bearer token injection
RegistryAuth/RegistryOAuthConfigconfig structs with mandatory PKCE(S256) — no opt-out flag, no client secret (public clients only)
DeriveSecretKeyusingsha256(registryURL + "\x00" + issuer)[:4]forunique per-registry secret storage keys
WithInteractive()functional option toNewRegistryProvidersothv serve(headless) returnsErrRegistryAuthRequiredinstead of blockingon a browser flow
AuthManagerbusiness logic and CLI commands:thv config set-registry-auth/unset-registry-authclient; skip validation probe when auth is configured
offline_accessso providers return refresh tokensRelates to https://github.com/stacklok/toolhive-rfcs/blob/main/rfcs/THV-0043-registry-authentication.md
Changes
pkg/config/config.goRegistryAuth,RegistryOAuthConfigstructs,RegistryAuthTypeOAuthconstantpkg/registry/auth/auth.goTokenSourceinterface,NewTokenSourcefactory,DeriveSecretKey,ErrRegistryAuthRequiredpkg/registry/auth/oauth_token_source.gopkg/registry/auth/transport.goRoundTripperwrapper injecting Bearer tokenspkg/registry/auth_manager.goAuthManagerinterface with OIDC discovery validationpkg/registry/factory.goWithInteractiveoption,resolveTokenSource()with secrets degradation loggingpkg/registry/provider_api.gopkg/registry/provider_cached.gopkg/registry/api/client.goauth.WrapTransportcmd/thv/app/config_registryauth.gothv config set-registry-auth/unset-registry-authcommandspkg/registry/auth/auth_test.gopkg/registry/auth/transport_test.gopkg/registry/auth_manager_test.goDoes this introduce a user-facing change?
Yes. Two new CLI commands:
thv config set-registry-auth --issuer <url> --client-id <id> [--scopes <list>] [--audience <value>]— configure OAuth for a remote registrythv config unset-registry-auth— remove registry auth configurationWhen a registry API URL is configured with auth, the CLI automatically handles
token acquisition via browser-based OAuth, with refresh tokens cached in the
secrets manager for subsequent invocations.
Special notes for reviewers
--use-pkceflag; always S256 per OAuth 2.1ClientSecretfield; PKCE replaces it(
ListServerswith limit=1) is skipped because it would trigger a browser flowbefore the user intends to use the registry
in-memory only for the current session — no persistence, but no failure
thv registry login/logout, API auth status fields, andHTTP 401/403 detection are planned for follow-up PRs per RFC-0043
Large PR Justification
🤖 Generated with Claude Code