startAuthorization silently redirects to wrong URL when AS metadata discovery fails for non-root paths

[RyanDJLee]

Bug: startAuthorization silently redirects to wrong URL when AS metadata discovery fails

Package: packages/client/src/client/auth.ts

Problem

When discoverAuthorizationServerMetadata() returns undefined (all discovery URLs returned 4xx or were unreachable), startAuthorization() falls back to constructing the authorization URL as:

authorizationUrl = new URL('/authorize', authorizationServerUrl);

new URL('/authorize', authorizationServerUrl) uses an absolute path, which replaces the entire pathname of authorizationServerUrl. When the authorization server has a subpath (e.g. https://example.com/admin), the result is https://example.com/authorize — the /admin prefix is silently lost.

The same pattern exists for the token endpoint fallback in executeTokenRequest():

const tokenUrl = metadata?.token_endpoint ? new URL(metadata.token_endpoint) : new URL('/token', authorizationServerUrl);

And the registration endpoint fallback in registerClient():

registrationUrl = new URL('/register', authorizationServerUrl);

Reproduction

1. PRM (/.well-known/oauth-protected-resource) returns authorization_servers: ["https://example.com/admin"]
2. AS metadata discovery at https://example.com/.well-known/oauth-authorization-server/admin returns 404
3. SDK constructs new URL('/authorize', 'https://example.com/admin') → https://example.com/authorize
4. User is redirected to a nonexistent authorization endpoint
5. The actual correct endpoint (https://example.com/admin/oauth/authorize) is never reached

Impact

• Silent failure: no error is thrown; the user sees a broken redirect with no diagnostic info
• Path loss: any authorization server with a non-root path is affected
• Masks real errors: the actual cause (AS metadata unreachable) is hidden behind a mysterious redirect failure

Proposed fix

When metadata is undefined and the authorization server URL has a non-root path, throw an error instead of guessing. The fallback to /authorize, /token, and /register should only apply when the AS is at the domain root (where it's a reasonable guess per RFC 6749 defaults).

Affected locations:

• startAuthorization() — /authorize fallback (line ~1204)
• executeTokenRequest() — /token fallback (line ~1286)
• registerClient() — /register fallback (line ~1533)

[lanxevo3]

Fixed in PR #1807 — added guards at all three URL fallback locations (/authorize, /token, /register) to throw an informative error when pathname !== '/' instead of silently producing broken URLs.

[mcp-claude]

confirmed bug: new URL('/authorize', 'https://example.com/admin') → https://example.com/authorize — the subpath /admin is silently dropped. affects all three metadata-discovery fallback paths in packages/client/src/client/auth.ts (lines 1375, 1457, 1704 on main; 1147, 1229, 1459 on v1.x). present on both branches.

the fix is to use a relative path with a trailing-slash base:

const base = authorizationServerUrl.toString().replace(/\/?$/, '/');
authorizationUrl = new URL('authorize', base);  // https://example.com/admin/authorize

workaround: ensure the authorization server is at a root path (no subpath), or configure an MCP server that returns correct metadata so the fallback is never reached.

repro script, output, and code path

repro.ts (run from repo root: npx tsx repro.ts):

function testUrlConstruction(label: string, path: string, base: string): void {
  const result = new URL(path, base);
  const expected = base.replace(/\/?$/, '') + path;
  const isWrong = result.toString() !== expected;
  console.log(`[${label}]`);
  console.log(`  new URL('${path}', '${base}') => ${result.toString()}`);
  console.log(`  BUG: ${isWrong ? 'YES - path dropped!' : 'no'}`);
}

// root base — no bug
testUrlConstruction('root base / authorize', '/authorize', 'https://example.com');
// subpath base — bug
testUrlConstruction('subpath base / authorize (startAuthorization fallback)', '/authorize', 'https://example.com/admin');
testUrlConstruction('subpath base / token (executeTokenRequest fallback)', '/token', 'https://example.com/admin');
testUrlConstruction('subpath base / register (registerClient fallback)', '/register', 'https://example.com/admin');

// correct approach
const base = 'https://example.com/admin/';
console.log(`correct: new URL('authorize', '${base}') => ${new URL('authorize', base)}`);

output:

[root base / authorize]
  new URL('/authorize', 'https://example.com') => https://example.com/authorize
  BUG: no
[subpath base / authorize (startAuthorization fallback)]
  new URL('/authorize', 'https://example.com/admin') => https://example.com/authorize
  BUG: YES - path dropped!
[subpath base / token (executeTokenRequest fallback)]
  new URL('/token', 'https://example.com/admin') => https://example.com/token
  BUG: YES - path dropped!
[subpath base / register (registerClient fallback)]
  new URL('/register', 'https://example.com/admin') => https://example.com/register
  BUG: YES - path dropped!
correct: new URL('authorize', 'https://example.com/admin/') => https://example.com/admin/authorize

code path:

• startAuthorization(): when discoverAuthorizationServerMetadata() returns undefined, falls to auth.ts:1375 — authorizationUrl = new URL('/authorize', authorizationServerUrl)
• executeTokenRequest(): when metadata is nullish, auth.ts:1457 — new URL('/token', authorizationServerUrl)
• registerClient(): when metadata is nullish, auth.ts:1704 — registrationUrl = new URL('/register', authorizationServerUrl)

all three use an absolute-path reference; WHATWG URL parsing replaces the entire path, discarding any existing subpath in the base.

suggested fix

// packages/client/src/client/auth.ts
-        authorizationUrl = new URL('/authorize', authorizationServerUrl);
+        authorizationUrl = new URL('authorize', authorizationServerUrl.toString().replace(/\/?$/, '/'));

-    const tokenUrl = metadata?.token_endpoint ? new URL(metadata.token_endpoint) : new URL('/token', authorizationServerUrl);
+    const tokenUrl = metadata?.token_endpoint ? new URL(metadata.token_endpoint) : new URL('token', authorizationServerUrl.toString().replace(/\/?$/, '/'));

-        registrationUrl = new URL('/register', authorizationServerUrl);
+        registrationUrl = new URL('register', authorizationServerUrl.toString().replace(/\/?$/, '/'));

test to verify: three tests checking that when no metadata is provided and the auth server URL has a subpath (e.g. https://auth.example.com/admin), the fallback endpoints (/admin/authorize, /admin/token, /admin/register) preserve the subpath rather than dropping it.

[pcarleton]

👋 copying a comment over from #1724

Those fallbacks are due to this section of the 2025-03-26 specification which does say that the root is the correct fallback even if there is a path: https://modelcontextprotocol.io/specification/2025-03-26/basic/authorization#fallbacks-for-servers-without-metadata-discovery

For example, with an MCP server hosted at https://api.example.com/v1/mcp, the default endpoints would be:
https://api.example.com/authorize
https://api.example.com/token
https://api.example.com/register

We've removed this from the specification because it causes problems, but we've kept the fallback to support servers that followed that specification version.

I would be supportive of making those fallbacks available to opt-out in v1 and actually require opt-in for v2 or potentially remove them entirely in v2.

I don't think we should pursue the error throwing approach though. Fallback removal should likely be a separate issue though, these fallbacks are currently "working as intended" for backwards compatibility.