fix(auth): callback iss must equal metadata issuer (honor metadataIssuer override)

[felixweinberger]

The mock AS's authorization-response iss and its published metadata issuer are the same identifier by definition (RFC 9207 §2: "the authorization server's issuer identifier ... MUST be identical to the value in the issuer field of the authorization server metadata"). RFC 9207 §2.4 then requires clients to compare the received iss against the metadata issuer via simple string comparison and reject on any difference.

createAuthServer derived these two values independently:

• metadata issuer honors metadataIssuer (since fix(auth): make 2025-03-26 backcompat mock RFC 8414 §3.3-compliant #359)
• callback iss='correct' was still getAuthBaseUrl() + routePrefix

So a scenario that sets metadataIssuer (to satisfy RFC 8414 §3.3) while keeping a routePrefix — exactly what auth/2025-03-26-oauth-metadata-backcompat does after #359 — produces a mock whose callback iss doesn't match its own metadata. An RFC 9207-conforming client correctly rejects it, and the scenario becomes un-passable for the wrong reason.

This extracts a single resolveIssuer() and uses it for both the metadata issuer and the 'correct'/'normalized' callback iss, so they're identical by construction. Scenarios that want a deliberate mismatch already use issInRedirect: 'wrong', which is unchanged.

Motivation and Context

Follow-up to #359. Surfaced by typescript-sdk#2344 turning RFC 9207 validation default-on: IssuerMismatchError: expected "http://localhost:45193", received "http://localhost:45193/oauth".

How Has This Been Tested?

Ran auth/2025-03-26-oauth-metadata-backcompat against typescript-sdk at the SEP-2468 head; passes with this change (fails without). Existing iss-* scenarios unaffected (they don't set metadataIssuer, so resolveIssuer() falls through to the original derivation).

Breaking Changes

None — resolveIssuer() returns exactly what each call site computed before when metadataIssuer is unset.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Documentation update

Checklist

• I have read the MCP Documentation
• My code follows the repository's style guidelines
• New and existing tests pass locally
• I have added appropriate error handling
• I have added or updated documentation as needed

Additional context

Once this lands in a published release, typescript-sdk can drop the auth/2025-03-26-oauth-metadata-backcompat expected-failure entry.

[pkg-pr-new]

Open in StackBlitz

npx https://pkg.pr.new/@modelcontextprotocol/conformance@361

commit: 8a6fcba