Files
worldmonitor/api/oauth-protected-resource.ts
Elie Habib d75bde4e03 fix(agent-readiness): host-aware oauth-protected-resource endpoint (#3351)
* fix(agent-readiness): host-aware oauth-protected-resource endpoint

isitagentready.com enforces that `authorization_servers[*]` share
origin with `resource` (same-origin rule, matches Cloudflare's
mcp.cloudflare.com reference — RFC 9728 §3 permits split origins
but the scanner is stricter).

A single static file served from 3 hosts (apex/www/api) can only
satisfy one origin at a time. Replacing with an edge function that
derives both `resource` and `authorization_servers` from the
request `Host` header gives each origin self-consistent metadata.

No server-side behavior changes: api/oauth/*.js token issuer
doesn't bind tokens to a specific resource value (verified in
the previous PR's review).

* fix(agent-readiness): host-derive resource_metadata + runtime guardrails

Addresses P1/P2 review on this PR:

- api/mcp.ts (P1): WWW-Authenticate resource_metadata was still
  hardcoded to apex even when the client hit api.worldmonitor.app.
  Derive from request.headers.get('host') so each client gets a
  pointer matching their own origin — consistent with the host-
  aware edge function this PR introduces.
- api/oauth-protected-resource.ts (P2): add Vary: Host so any
  intermediate cache keys by hostname (belt + suspenders on top of
  Vercel's routing).
- tests/deploy-config.test.mjs (P2): replace regex-on-source with
  a runtime handler invocation asserting origin-matching metadata
  for apex/www/api hosts, and tighten the api/mcp.ts assertion to
  require host-derived resource_metadata construction.

---------

Co-authored-by: Elie Habib <elie@worldmonitor.app>
2026-04-23 21:17:32 +04:00

1.8 KiB