Advertise canonical OAuth discovery while retaining legacy routes

[rgarcia]

Summary

• Advertise canonical https://auth.onkernel.com OAuth endpoints in production protected-resource discovery, while preserving the resource identity https://mcp.onkernel.com.
• Keep local/staging/preview discovery on its existing origin and mark discovery responses no-store.
• Leave every legacy TypeScript OAuth route, authorization-server metadata, middleware, MCP transport, registration, and token behavior unchanged. No relay, client import, or migration fallback.
• Document forward/reverse deployment ordering and cached-client constraints in docs/oauth-cutover.md.

Deployment dependencies

Ready for code review, not authorization to merge/deploy.

1. Resolve cached-client compatibility/recovery, including clients already using the auth hostname. Retaining legacy routes does not make cached registration IDs valid on the canonical Go issuer.
2. Release the separate auth DNS-only change and verify public canonical DNS/TLS/service/callback usability. Keep MCP DNS/hosting unchanged.
3. Only then merge/deploy this discovery change and verify metadata, resource identity, and retained legacy paths.

Reverse ordering: deploy a focused metadata rollback from current main first; keep auth on Go while handling cached canonical clients and in-flight codes. A separately reviewed auth-record-only DNS rollback comes after that, with its captured target and TTL convergence checks. Neither metadata nor DNS rollback is guaranteed to transparently recover cached clients. Do not revert unrelated concurrent work or delete registrations.

Cached-client compatibility fixture

Synthetic native-client testing with Claude Code 2.1.259 found:

• Ordinary cached clients retain their legacy issuer, client ID, and authorization/token endpoints after discovery changes; login and expired-token refresh succeed with legacy TypeScript routes retained. There is no automatic migration.
• An explicit canonical issuer override with an old client ID sends that stale ID to canonical authorization. A direct 400 invalid_request does not immediately clear it: early cancellation preserves it, while the observed 300.3-second callback timeout clears it. Token-stage invalid_client is different and clears registration immediately.
• In the isolated fixture, claude mcp logout <server-name> followed by claude mcp login <server-name> immediately removes the stale registration and performs successful canonical DCR on the next login. Ordinary cached users did not need this recovery while legacy routes remained available.

This is synthetic evidence for the tested client/version, not live acceptance or a guarantee for all clients. It does not authorize cutover or replace the remaining live acceptance checks. Keep the legacy routes; do not infer that existing IDs are valid across issuers.

Validation

• Focused discovery + existing OAuth route/conformance tests: 30 passed.
• Full suite on Bun 1.3.3: 608 passed.
• bunx tsc --noEmit --incremental false: passed.
• Changed-file Prettier and git diff --check: passed.
• Full diff deslop/self-review completed; legacy route/middleware/transport files match main.

No deployment, public setting, DNS, Clerk, or live registration changes performed. Cached-client compatibility testing is separate from these local tests.

[vercel]

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

Project	Deployment	Actions	Updated
mcp	Ready	Preview	Sep 17, 2026 2:27pm UTC

[cursor]

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

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

^{Reviewed by Cursor Bugbot for commit f216674. Configure here.}

[masnwilliams]

Reviewed at 0d6c1ce. The discovery policy is small, explicit, and well isolated; production preserves the MCP resource identity while advertising the canonical authorization server, and non-production remains self-originating. The regression coverage addresses the public-host behavior across staging, previews, and local development. No actionable code-quality findings.

The documented DNS and cached-client checks should remain deployment gates.