test: add failing test for redirect URI case sensitivity

[webjunkie]

PR #1508 (wildcard support) changed redirect URI comparison to use parsed_uri.hostname instead of netloc. Since .hostname auto-lowercases, https://EXAMPLE.COM now matches https://example.com.

OAuth 2.0 Security BCP suggests exact string matching for redirect URIs - is this change intentional?

Adding a test that passes on 3.0.1 but fails on master to clarify expected behavior.

[n2ygk]

@webjunkie Please provide a link to the BCP document section that states this.

[webjunkie]

@n2ygk

Happy to provide that! So rfc9700 states in 4.1.3:

This means the authorization server MUST ensure that the two URIs are equal; see Section 6.2.1 of [RFC3986], Simple String Comparison, for details.

It only references 6.2.1, which states:

In practical terms, character-by-character comparisons should be done codepoint-by-codepoint after conversion to a common character encoding.

That does not include any normalization or case-folding (that's 6.2.2, which seems intentionally not referenced).

[dopry]

per RFC 3986, RFC 7230 hostnames in uris are not case sensitive. therefore a case insensitive comparison of hostname is required when checking if a uri is equal as per the RFC9700 that you reference.

[webjunkie]

Thanks for the clarification. I may be missing an intended interpretation here, but I’m concerned the current behavior is no longer “exact string matching” for redirect_uri.

Multiple specs/guidance documents explicitly call for exact matching / simple string comparison for redirect URIs:

• RFC 9700 (OAuth 2.0 Security BCP): requires “exact string matching” for redirect URIs (except the loopback port case) and intentionally points to RFC 3986 §6.2.1 (Simple String Comparison), not to the normalization or equivalence rules (e.g., case-insensitive host comparison) in §6.2.2 or in RFC 7230.
  • https://www.rfc-editor.org/rfc/rfc9700.html
• OAuth 2.1 draft: requires rejecting requests where redirect_uri “doesn’t exactly match” a registered one (again with loopback port exception).
  • https://datatracker.ietf.org/doc/draft-ietf-oauth-v2-1/
• OpenID Connect Core uses the same “MUST exactly match … matching performed as described in RFC 3986 §6.2.1” wording.
  • https://openid.net/specs/openid-connect-core-1_0.html#AuthRequest

Separately, major providers document strictness in practice. For example, Microsoft Entra states redirect URIs are case-sensitive (at least for the URL path) and must match what’s configured:

• https://learn.microsoft.com/en-us/entra/identity-platform/reply-url

If the maintainers prefer "semantic equivalence" for hostnames (case-insensitive host), could we at least:

1. document that redirect URI host matching is intentionally case-insensitive, and
2. consider making this behavior opt-in (since it diverges from the strict "exact string matching" guidance above)?