fix: serve RFC 9728 path-suffixed metadata, document connector redirect URIs

Two separate discovery footguns, both found while debugging an Authentik
"Redirect URI Error" on a claude.ai custom connector.

RFC 9728 §3.1 puts the metadata for a resource identified by
`https://host/api/mcp` at `/.well-known/oauth-protected-resource/api/mcp`.
Only the root form was served, so clients that derive the metadata URL from
the MCP endpoint URL — rather than reading `resource_metadata` off our 401 —
got Next.js's HTML 404 and failed discovery with a JSON parse error.

Add a `[...path]` route serving the same document with `resource` naming the
suffixed identifier (§3.3 has the client compare it as an exact string, so
echoing the bare origin would be rejected). The document body moves to
`lib/auth/resource-metadata.ts` so the two routes cannot drift apart on
`scopes_supported` — a divergence there costs you the `aud` claim or the
refresh token. Paths are allowlisted rather than wildcarded so this cannot
advertise resources the app does not serve. `buildWwwAuthenticate()` still
points at the root URL; this change is purely additive.

Separately, the redirect URIs an MCP provider needs depend on how clients
reach it: a loopback URI for the CLI, `https://claude.ai/api/mcp/auth_callback`
for a claude.ai custom connector. Registering only the former is what produces
the "Redirect URI Error" page, and a portless `http://localhost/callback`
entry matches nothing the CLI sends. Document both, keyed on the literal
error text, and note that DCR is enterprise-gated on Authentik so these are
hand-registered on a FOSS instance.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

apps/web/app/.well-known/oauth-protected-resource/[...path]/route.ts

@@ -0,0 +1,60 @@
+import { NextResponse } from "next/server";
+import { buildResourceMetadata, publicOrigin } from "@/lib/auth/resource-metadata";
+
+export const runtime = "nodejs";
+export const dynamic = "force-dynamic";
+
+/**
+ * Resource paths this deployment will publish metadata for.
+ *
+ * An allowlist rather than a wildcard, for two reasons. RFC 9728 §3.1 maps a
+ * metadata URL to one specific protected resource, so answering for arbitrary
+ * paths would advertise resources this app does not serve — a client could
+ * "discover" `https://host/anything` as an OAuth-protected resource and be
+ * told, wrongly, that tokens for it are obtainable from our IdP. And every
+ * path that answers is surface: a wildcard turns this into an open reflector
+ * that echoes attacker-chosen path segments back inside a JSON document.
+ *
+ * `api/mcp` is the only MCP endpoint here (app/api/mcp/route.ts). Add an
+ * entry when a second one ships — not before.
+ */
+const METADATA_RESOURCE_PATHS: ReadonlySet<string> = new Set(["api/mcp"]);
+
+/**
+ * RFC 9728 §3.1 — path-suffixed protected resource metadata.
+ *
+ * For a resource identified by `https://host/api/mcp`, the spec puts its
+ * metadata at `https://host/.well-known/oauth-protected-resource/api/mcp`:
+ * the resource's path is appended to the well-known path. Clients that derive
+ * the metadata URL from the MCP endpoint URL — rather than reading
+ * `resource_metadata` off our 401's `WWW-Authenticate` header — probe that URL
+ * first, and before this route existed they got Next.js's 404 HTML page, which
+ * fails discovery with a JSON parse error rather than anything diagnosable.
+ *
+ * The document is identical to the root one except for `resource`, which must
+ * name the suffixed identifier: §3.3 requires the client to check that the
+ * returned `resource` equals the identifier it asked about, so echoing the
+ * bare origin here would make a strict client reject the document outright.
+ */
+export async function GET(
+  _req: Request,
+  ctx: { params: Promise<{ path: string[] }> },
+): Promise<NextResponse> {
+  const { path } = await ctx.params;
+  // Segments arrive already percent-decoded and never empty, but join and
+  // compare on the same normalized form the allowlist is written in.
+  const resourcePath = path.join("/");
+
+  if (!METADATA_RESOURCE_PATHS.has(resourcePath)) {
+    // JSON, not the HTML 404 page, so a client that probes a wrong path gets
+    // a parseable answer instead of the failure mode this route exists to fix.
+    return NextResponse.json(
+      { error: "not_found", error_description: "no such protected resource" },
+      { status: 404 },
+    );
+  }
+
+  return NextResponse.json(
+    buildResourceMetadata(`${publicOrigin()}/${resourcePath}`),
+  );
+}