fix(auth): make 2025-03-26 backcompat mock RFC 8414 §3.3-compliant - #359
Merged
pcarleton merged 2 commits intoJun 23, 2026
Merged
Conversation
Copy link
Copy Markdown
Collaborator
Sorry, something went wrong.
Drop the routePrefix from auth/2025-03-26-oauth-metadata-backcompat. The prefix caused createAuthServer to report issuer:'<origin>/oauth' while serving the metadata at the root /.well-known/oauth-authorization-server — an RFC 8414 §3.3 mismatch a conforming client must reject. The MCP server in this scenario only mounts /mcp, so the unprefixed /authorize, /token, /register routes do not collide (the sibling endpoint-fallback scenario already mounts them at root). The scenario continues to test exactly what it's meant to: 2025-03-26-spec discovery with no PRM, OAuth metadata at the root well-known path.
Copy link
Copy Markdown
npx https://pkg.pr.new/@modelcontextprotocol/conformance@359 commit: 7640176 |
Sorry, something went wrong.
…er instead Dropping routePrefix made the metadata-advertised endpoints land on the 2025-03-26 hardcoded fallback paths, so a client that fetches the well-known doc but ignores its body would now pass. Restore the prefix and pin the metadata issuer to the bare origin via a lazy metadataIssuer override so the mock is RFC 8414 §3.3-compliant without losing the fallback-vs-metadata distinction.
pcarleton
approved these changes
Jun 23, 2026
This was referenced Jun 23, 2026
pcarleton
pushed a commit
that referenced
this pull request
Jun 24, 2026
…uer override) (#361) #359 made the metadata `issuer` honor the metadataIssuer override so the 2025-03-26 backcompat scenario is RFC 8414 §3.3-compliant. The authorize callback's `iss` parameter was still derived as `getAuthBaseUrl()+routePrefix`, so when a scenario sets metadataIssuer (bare origin) but keeps a routePrefix, the callback `iss` mismatches the metadata `issuer` and an RFC 9207-conforming client correctly rejects it. Extract `resolveIssuer()` and use it for both the metadata `issuer` and the `'correct'`/`'normalized'` callback `iss` so they always match.
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.
The auth/2025-03-26-oauth-metadata-backcompat scenario tests that an MCP client can still discover and authenticate when the server uses the March 2025 spec layout: no Protected Resource Metadata, OAuth Authorization Server Metadata served at the root /.well-known/oauth-authorization-server. That property is still worth testing in --suite all.
The mock's configuration has a latent bug unrelated to that property: it passes routePrefix: '/oauth', which makes createAuthServer report issuer: '<origin>/oauth' in the metadata while serving that metadata at the root well-known path. RFC 8414 §3.3 requires that "the issuer value returned MUST be identical to the authorization server's issuer identifier value into which the well-known URI string was inserted" — i.e., metadata served at the root well-known path must have issuer: '<origin>' with no path component. A real March-2025-era authorization server following RFC 8414 (published 2018) would have been compliant; the mismatch here is an artifact of how routePrefix and the default metadataPath interact.
This was invisible until SEP-2468 made the §3.3 check a client MUST in the 2026-07-28 spec (authorization-server-discovery.mdx: "the issuer value in the document MUST be identical to the issuer identifier used to construct the well-known URL. If they differ, the client MUST NOT use the metadata"). A client implementing that MUST now correctly rejects the mock's metadata, so the scenario and SEP-2468 cannot both pass as written.
Motivation and Context
Dropping routePrefix makes the mock §3.3-compliant without changing what the scenario tests. The route prefix existed to avoid collisions with the MCP server routes, but createServer only mounts /mcp (and the PRM path, which is null here), so unprefixed /authorize, /token, /register are fine — the sibling auth/2025-03-26-oauth-endpoint-fallback scenario in the same file already mounts them at root.
How Has This Been Tested?
CI will verify; local npm ci was blocked by registry access in my environment. The change is a single options-property removal.
Breaking Changes
None — fixes a mock configuration bug; no API or behavior change for clients that don't enforce §3.3.
Types of changes
Checklist
Additional context
Surfaced while landing SEP-2468 in typescript-sdk: with §3.3 default-on, this is the only auth/* scenario that regresses, and only because of the mock's issuer/well-known mismatch.