Skip to content

Correct OAuth protected-resource identity and discovery challenges - #206

Open
rgarcia wants to merge 2 commits into
mainfrom
hypeship/fix-oauth-resource-metadata
Open

rgarcia wants to merge 2 commits into
mainfrom
hypeship/fix-oauth-resource-metadata

Conversation

@rgarcia

@rgarcia rgarcia commented Sep 18, 2026

Copy link
Copy Markdown
Contributor

Summary

Correct the protected-resource identifier from the origin-only URL to https://mcp.onkernel.com/mcp. RFC 9728 §3.3 requires it to match the resource used to derive /.well-known/oauth-protected-resource/mcp; strict discovery clients reject the previous value.

  • Preserve the canonical production authorization server, environment-specific local/staging/preview origins, no-store, and legacy OAuth routes and credential storage.
  • Include the path-specific metadata URL in MCP 401 challenges. Let /mcp reach the existing bearer-token validation instead of Clerk page protection; other protected pages remain protected.
  • Cover exact path/resource binding, internal-origin/public-Host handling, route metadata/CORS/cache behavior, GET/POST challenges, middleware routing, and unchanged legacy token-resource forwarding.
  • Update the cutover contract, compatibility prerequisites, and rollback guidance without changing DNS or deployment configuration. No root protected-resource metadata endpoint is added.

Rollout gate — do not merge/deploy yet

Deploy companion client issuer/registration/resource pinning and explicit reconnect handling before this correction. Accepting corrected discovery must not silently move retained credentials to a different issuer during callback or refresh. Existing registrations do not automatically migrate.

Preserve old in-flight resource bindings exactly: the Go broker accepts /mcp, but token exchange compares against the resource stored in the authorization transaction. The retained TypeScript token route continues forwarding origin-only, /mcp, or omitted resources without rewriting them. Cached-client recovery and live token/refresh compatibility remain separately authorized rollout checks.

Validation

Using Bun 1.3.3 (matching CI):

  • bun test: 656 passed, 0 failed across 59 files.
  • bunx tsc --noEmit --incremental false: passed.
  • bun run check:managed-auth-app: passed.
  • Prettier check on all changed files and git diff --check: passed.

No live registration, authorization, token, or refresh probes were run. Metadata route tests mock Clerk discovery; token tests inject mock dependencies. No full Next.js build or local Redis recording regeneration was run. No production, DNS, or credential changes were made.

@vercel

vercel Bot commented Sep 18, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated
mcp Ready Ready Preview Sep 18, 2026 9:35pm UTC

@masnwilliams masnwilliams left a comment

Copy link
Copy Markdown
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Verified the protected-resource metadata and unauthenticated MCP challenge against the preview deployment; both advertise the expected path-specific HTTPS resource and metadata URL. The test suite, typecheck, formatting for changed files, and CI pass.

Non-blocking cleanup: now that /mcp is public at the Clerk middleware layer, the later MCP-specific middleware branch no longer governs the canonical endpoint and can be removed separately. Keep the documented rollout sequencing in place.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants