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>
This commit is contained in:
@@ -0,0 +1,73 @@
|
||||
import { env } from "@/lib/env";
|
||||
import { mcpIssuer } from "@/lib/auth/jwt";
|
||||
|
||||
/**
|
||||
* The protected-resource metadata document, RFC 9728 §2.
|
||||
*
|
||||
* Shared by both metadata routes — the root `/.well-known/oauth-protected-
|
||||
* resource` and the path-suffixed `/.well-known/oauth-protected-resource/
|
||||
* <resource path>` form of §3.1 — because the two documents differ ONLY in
|
||||
* the `resource` identifier they describe. Anything else drifting between
|
||||
* them is a bug: a client that discovers us through the suffixed URL would
|
||||
* be told to request a different scope set than one that follows the
|
||||
* `WWW-Authenticate: resource_metadata=...` header, and whichever of the two
|
||||
* lost the audience scope would hand back tokens with no `aud` claim.
|
||||
*/
|
||||
export interface ResourceMetadata {
|
||||
resource: string;
|
||||
authorization_servers: string[];
|
||||
scopes_supported: string[];
|
||||
bearer_methods_supported: string[];
|
||||
resource_documentation: string;
|
||||
}
|
||||
|
||||
/**
|
||||
* The public origin, with any trailing slash stripped.
|
||||
*
|
||||
* `resource` values are compared as exact strings by clients (RFC 9728 §3.3),
|
||||
* so `https://host/` and `https://host` are not interchangeable — PUBLIC_URL
|
||||
* is written both ways in the wild and only the stripped form is emitted.
|
||||
*/
|
||||
export function publicOrigin(): string {
|
||||
return env().PUBLIC_URL.replace(/\/$/, "");
|
||||
}
|
||||
|
||||
/**
|
||||
* Build the metadata document for `resource`.
|
||||
*
|
||||
* The caller supplies the resource identifier because it depends on which
|
||||
* URL the document was fetched from; everything else is deployment config.
|
||||
*/
|
||||
export function buildResourceMetadata(resource: string): ResourceMetadata {
|
||||
// The audience scope MUST be advertised. Authentik only evaluates a scope
|
||||
// mapping when the client requests that scope by name, and the client only
|
||||
// learns scope names from this document. Omit it and every access token
|
||||
// arrives without `aud`, which jwt.ts rejects as "claim invalid: aud".
|
||||
const audienceScope =
|
||||
env().OIDC_AUDIENCE_SCOPE ?? `aud-${env().OIDC_AUDIENCE}`;
|
||||
|
||||
// Same mechanism as the audience scope, different consequence: a client
|
||||
// only requests `offline_access` if it sees the name here, and without
|
||||
// that request the IdP returns no refresh token — so the client cannot
|
||||
// renew and the user gets kicked back to an interactive login whenever
|
||||
// the access token expires.
|
||||
//
|
||||
// Opt-in, because the IdP needs a matching scope mapping; advertising one
|
||||
// it doesn't offer can fail the whole authorization request.
|
||||
const scopes = ["openid", "profile", "email", audienceScope];
|
||||
if (env().OIDC_OFFLINE_ACCESS) scopes.push("offline_access");
|
||||
|
||||
return {
|
||||
resource,
|
||||
// The MCP application's issuer, which is not necessarily the Web UI's —
|
||||
// see mcpIssuer(). Advertising the wrong one sends clients to a discovery
|
||||
// document whose tokens this endpoint will then reject on `iss`.
|
||||
authorization_servers: [mcpIssuer()], // as configured, slash and all
|
||||
scopes_supported: scopes,
|
||||
bearer_methods_supported: ["header"],
|
||||
// Documentation lives at the site root regardless of which resource this
|
||||
// document describes, so it is always derived from the public origin and
|
||||
// not from `resource`.
|
||||
resource_documentation: `${publicOrigin()}/`,
|
||||
};
|
||||
}
|
||||
Reference in New Issue
Block a user