Section 4.5 Redirect URIs

[ThisIsMissEm]

Also from #79, Section 4.5 specifies some language for Redirect URIs, https://www.ietf.org/archive/id/draft-ietf-oauth-client-id-metadata-document-01.html#name-redirect-url-registration

We may want to consider aligning this text with OAuth 2.1's text: https://datatracker.ietf.org/doc/html/draft-ietf-oauth-v2-1#section-4.1.1-28

In particular, the authorization server MUST validate the redirect_uri in the request if present, ensuring that it matches one of the registered redirect URIs previously established during client registration (Section 2). When comparing the two URIs the authorization server MUST ensure that the two URIs are equal, see Section 6.2.1 of [RFC3986], Simple String Comparison, for details. The only exception is native apps using a localhost URI: In this case, the authorization server MUST allow variable port numbers as described in Section 7.3 of [RFC8252].

Or specify it in a way that directly references the normative model for redirect URIs and registration / validation of them.

[localden]

+1. We hit this in practice with Claude Code's CIMD client metadata: at least one implementer (FastMCP, before PrefectHQ/fastmcp#3589) read the current Section 4.5 wording as unconditional exact-match and rejected ephemeral-port loopback redirects from a native client whose redirect_uris were registered portless per RFC 8252 Section 7.3. Their fix cited 7.3 directly, but Section 4.5 gave them no hint the exception applied.

One thing worth making explicit alongside the OAuth 2.1 text: the "native apps" condition in that exception ties to application_type (per RFC 8252 Section 8.4), which connects this to #75. A client metadata document that omits application_type defaults to web, so an authorization server reading the proposed text strictly wouldn't apply the loopback exception unless the document sets application_type: "native".