Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

auth: resource metadata lookup accepts URLs from non-Bearer challenges

Open Beginner friendly
  • Is something wrong?
#1,379 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
2/5
Estimated time
1-3 hours
Newbie friendliness
82/100
Issue type
Bug
Clarity
Clearly specified
Activity status
Active
Tech stack
go
Domain
authentication, backend-api-design

Research direction

Read resourceMetadataURLFromChallenges and compare its filtering with scopesFromChallenges and errorFromChallenges. Run the package-level regression test shown in the issue, then add it alongside the helper's existing tests. Done means non-Bearer challenges are ignored and the Bearer challenge's resource metadata URL is returned.

Written by the indexing model from the issue text.

Description

Describe the bug

auth.resourceMetadataURLFromChallenges returns the first resource_metadata auth-param without checking the challenge scheme. The adjacent scopesFromChallenges and errorFromChallenges helpers correctly restrict their lookups to Bearer challenges.

As a result, a mixed response such as:

WWW-Authenticate: Basic resource_metadata="https://basic.example/metadata", Bearer resource_metadata="https://mcp.example/metadata"

causes AuthorizationCodeHandler to discover OAuth metadata from https://basic.example/metadata, even though resource_metadata is an MCP Bearer-challenge parameter and the Bearer challenge points elsewhere.

To Reproduce

On main at 944ac19, this package-level test fails:

func TestResourceMetadataURLFromChallengesIgnoresNonBearer(t *testing.T) {
	challenges := []oauthex.Challenge{
		{Scheme: "basic", Params: map[string]string{"resource_metadata": "https://basic.example/metadata"}},
		{Scheme: "bearer", Params: map[string]string{"resource_metadata": "https://mcp.example/metadata"}},
	}
	if got, want := resourceMetadataURLFromChallenges(challenges), "https://mcp.example/metadata"; got != want {
		t.Fatalf("resourceMetadataURLFromChallenges() = %q, want %q", got, want)
	}
}

The current result is https://basic.example/metadata.

Expected behavior

Only a Bearer challenge should supply resource_metadata, matching the filtering already used for scope and error. The current MCP authorization examples attach resource_metadata to the Bearer challenge, and RFC 6750 defines Bearer challenge parameters in WWW-Authenticate.

Additional context

The fix should be a small, unexported behavior correction: require c.Scheme == "bearer" in resourceMetadataURLFromChallenges and add the mixed-challenge regression test above. I would be happy to send that PR if this approach looks right.

Environment: go-sdk main at 944ac19, Go 1.25.0, macOS/arm64.

AI assistance disclosure: I used Codex to inspect the auth flow and draft the reproducer; I reviewed the source, specification references, and issue text.

Dominant language
Go
Stars
5.2k
Forks
583
Avg merge
1d 11h
Merged PRs (30d)
47

Getting set up

Open in Codespaces

Starts the project's dev container in your browser, under your own GitHub account.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from modelcontextprotocol/go-sdk

All issues in modelcontextprotocol/go-sdk

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.