extauth: add ClientCredentialsHandler for OAuth client credentials grant#895
Open
ravyg wants to merge 1 commit intomodelcontextprotocol:mainfrom
Open
extauth: add ClientCredentialsHandler for OAuth client credentials grant#895ravyg wants to merge 1 commit intomodelcontextprotocol:mainfrom
ravyg wants to merge 1 commit intomodelcontextprotocol:mainfrom
Conversation
ravyg
force-pushed
the
feat/627-oauth-client-credentials
branch
from
013c785 to
0977382
Compare
maciej-kisiel
requested changes
Apr 14, 2026
ravyg
force-pushed
the
feat/627-oauth-client-credentials
branch
from
8814ca6 to
6383b63
Compare
maciej-kisiel
requested changes
Apr 22, 2026
| // scopesFromChallenges extracts scope values from WWW-Authenticate challenges. | ||
| func scopesFromChallenges(cs []oauthex.Challenge) []string { | ||
| for _, c := range cs { | ||
| if s := c.Params["scope"]; s != "" { |
Contributor
There was a problem hiding this comment.
Why the difference in implementation from the AuthorizationCodeHandler? I believe we should split scopes into a slice instead of interpreting the space separated list as a single string.
| // getProtectedResourceMetadata discovers Protected Resource Metadata (RFC 9728) | ||
| // from the request URL. It tries the resource_metadata URL from WWW-Authenticate | ||
| // challenges first, then falls back to well-known discovery. | ||
| func getProtectedResourceMetadata(ctx context.Context, wwwChallenges []oauthex.Challenge, mcpServerURL string, httpClient *http.Client) (*oauthex.ProtectedResourceMetadata, error) { |
Contributor
There was a problem hiding this comment.
Is there a particular reason we're changing the logic compared to the AuthorizationCodeHandler? Why not just copy the logic, do we want different behavior?
| } | ||
| u.Path = "" | ||
| rootURL := u.String() | ||
| prm, err := oauthex.GetProtectedResourceMetadata( |
Contributor
There was a problem hiding this comment.
Please keep the call on a single line.
| func TestNewClientCredentialsHandler_Validation(t *testing.T) { | ||
| tests := []struct { | ||
| name string | ||
| modify func(*ClientCredentialsHandlerConfig) *ClientCredentialsHandlerConfig |
Contributor
There was a problem hiding this comment.
This doesn't need to be a function, just the config. You can change the function signature to take 0 arguments, create valid config inside the function and call the function immediately in the test case definition. This way the config creation is local and easy to reason about.
|
|
||
| // Set up a fake MCP server that returns PRM pointing to the auth server. | ||
| mcpMux := http.NewServeMux() | ||
| mcpMux.HandleFunc("/.well-known/oauth-protected-resource", func(w http.ResponseWriter, r *http.Request) { |
Contributor
There was a problem hiding this comment.
Please use auth.ProtectedResourceMetadataHandler like in the authorization_code_test.go.
Contributor
Author
|
taking a look |
ravyg
force-pushed
the
feat/627-oauth-client-credentials
branch
from
6383b63 to
4d96e06
Compare
Contributor
Author
|
found one issue, I am fixing it. |
Add an implementation of auth.OAuthHandler that uses the OAuth 2.0 Client Credentials grant (RFC 6749 Section 4.4) for service-to-service authentication with pre-registered credentials. This bypasses both dynamic client registration and the authorization code flow. The handler supports two modes: - Direct token endpoint URL - Metadata discovery via AuthServerURL (RFC 8414) Also adds client_credentials grant type support to the fake authorization server in internal/oauthtest for testing. Refs modelcontextprotocol#627
ravyg
force-pushed
the
feat/627-oauth-client-credentials
branch
from
4d96e06 to
2b46590
Compare
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
2 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
ClientCredentialsHandlerimplementingauth.OAuthHandlerusing the OAuth 2.0 Client Credentials grant (RFC 6749 Section 4.4) for service-to-service authentication with pre-registered credentials.TokenEndpointURL, or metadata discovery viaAuthServerURL(RFC 8414).client_credentialsgrant type support to the fake authorization server ininternal/oauthtestfor testing.Context
Per @jba's comment on #627:
The client-side OAuth scaffolding (#785) that this was blocked on is now complete, as @brkane noted.
Implements the client credentials variant of SEP-1046. The JWT Assertions variant (RFC 7523) is left for a follow-up as its API surface needs more design discussion.
Test plan
TestNewClientCredentialsHandler_Validation— validates all config error cases (nil config, missing fields, mutual exclusivity)TestClientCredentialsHandler_Authorize/direct_token_endpoint— end-to-end with fake auth serverTestClientCredentialsHandler_Authorize/metadata_discovery— discovers token endpoint via RFC 8414 metadataTestClientCredentialsHandler_Authorize/bad_credentials— verifies failure with wrong secretgo test ./... -count=1passesgo vet ./...cleanRefs #627