feat: add OAuth discovery endpoints for ChatGPT MCP compatibility

[ehfeng]

Summary

• Add /.well-known/oauth-protected-resource root-level route — ChatGPT strips the /mcp path suffix and checks the base URL, which was returning 404
• Add /.well-known/oauth-authorization-server route (RFC 8414) — the protected resource metadata declares authorization_servers: ["https://mcp.onkernel.com"], so OAuth clients follow that to discover AS capabilities; the missing endpoint caused ChatGPT to report "does not implement OAuth"

Context

ChatGPT's MCP connector failed with: "MCP server https://mcp.onkernel.com/ does not implement OAuth"

The existing /.well-known/oauth-protected-resource/mcp route was correct per RFC 9728 path construction, but ChatGPT also checks the root /.well-known/oauth-protected-resource and then follows authorization_servers to discover /.well-known/oauth-authorization-server — both of which were 404ing.

Test plan

• Deploy and verify https://mcp.onkernel.com/.well-known/oauth-protected-resource returns JSON (not 404)
• Verify https://mcp.onkernel.com/.well-known/oauth-authorization-server returns JSON with issuer, authorization_endpoint, token_endpoint, etc.
• Connect https://mcp.onkernel.com/mcp from ChatGPT Apps / MCP connector and confirm OAuth flow completes

🤖 Generated with Claude Code

---

Note

Medium Risk
Adds new public /.well-known/* OAuth discovery endpoints (with permissive CORS) that affect how clients locate auth/token servers; misconfiguration could break OAuth interoperability but does not change core token verification logic.

Overview
Adds RFC-style OAuth discovery metadata endpoints to improve MCP client compatibility.

Introduces /.well-known/oauth-authorization-server to publish authorization server capabilities (issuer, auth/token endpoints, JWKS, supported grants, and auth methods) derived from the current host plus NEXT_PUBLIC_CLERK_DOMAIN. Also adds a root /.well-known/oauth-protected-resource endpoint (in addition to the existing /mcp variant) that proxies Clerk-provided metadata and rewrites it to point clients at this server’s /authorize and /token, returning CORS-enabled JSON responses for both GET and OPTIONS.

^{Written by Cursor Bugbot for commit 40a0a2e. This will update automatically on new commits. Configure here.}

[vercel]

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

Project	Deployment	Actions	Updated (UTC)
mcp	Ready	Preview, Comment	Mar 9, 2026 6:18pm

[cursor]

Risk assessment for this PR: Medium.

Rationale based on the actual diff:

1. Adds two new public /.well-known/* OAuth discovery endpoints in production code.
2. Changes externally consumed auth metadata (issuer, authorization_endpoint, token_endpoint, and authorization_servers) that OAuth clients depend on.
3. Touches auth-adjacent behavior and interoperability surface area, where regressions can break login/connect flows.

Decision:

1. Code review required before merge.
2. Not self-approving due to Medium risk and required review.
3. Requested reviewer: @masnwilliams (primary recent contributor/expert in related OAuth route codepaths).

---

  

[cursor]

Cursor Bugbot has reviewed your changes and found 1 potential issue.

^{Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.}

[cursor]

Root protected-resource route duplicates existing mcp route

Low Severity

The new oauth-protected-resource/route.ts is a byte-for-byte duplicate of the existing oauth-protected-resource/mcp/route.ts. Both files share the same handler logic, CORS headers, and metadata construction. Extracting the shared handler into a common module would avoid the risk of the two copies drifting apart when future changes are made to only one of them.

 

[masnwilliams]

@ehfeng were you able to test this out to see if it works with ChatGPT? happy to help test — we've tried something similar before and it ended up breaking other MCP clients like Cursor for some reason, so want to make sure we validate across clients before merging.

[masnwilliams]

some notes from reviewing:

1. cors duplication — the same 3-header cors block is copy-pasted ~6 times across the well-known routes (OPTIONS handler, GET response, times 3 files). might be worth extracting a shared corsHeaders constant to keep them in sync.

2. issuer derived from request host (line 28 in oauth-authorization-server) — issuer will reflect whatever hostname the request arrives at (e.g. localhost:3000 in dev). works fine in prod assuming no CDN/proxy rewrites the host, but worth confirming there are no surprises there.

3. metadata is fully hardcoded — unlike the protected-resource route which calls protectedResourceHandlerClerk and overrides fields, the authorization-server route builds the entire metadata object from scratch. if clerk's capabilities change (new grant types, etc.), this won't pick that up. probably fine since this server is the auth server facade, but a brief code comment noting that would help future readers.

4. mixed routing pattern — registration_endpoint points directly to clerk (clerkBaseUrl/oauth/register) while auth/token are proxied through this server. consistent with how the protected-resource route does it, just noting the pattern.

nothing blocking — overall looks good for unblocking chatgpt compatibility.