Clarify `client_id` Matching When HTTP Redirects Occur

[btiernay]

Clarify client_id Matching When HTTP Redirects Occur

Summary: Section 4.1 Client Metadata requires the client_id property to match "the URL of the document" but doesn't specify which URL to use when HTTP redirects occur during metadata fetch.

Current Specification Language

From Section 4.1 Client Metadata:

The client metadata document MUST contain a client_id property whose value MUST match the URL of the document using simple string comparison as defined in [RFC3986] Section 6.2.1.

The specification doesn't clarify what "the URL of the document" means when the authorization server follows HTTP redirects during the metadata fetch process.

Rationale

This ambiguity creates a potential security vulnerability. When an authorization server fetches a client metadata document and encounters HTTP redirects, it's unclear whether the client_id property should match:

1. The original client_id URL from the authorization request, or
2. The final URL after following redirects

Without clear guidance, different implementations might handle this differently, leading to inconsistent security properties. An attacker could potentially exploit this by setting up redirects from a URL they control to a legitimate metadata document, then claiming the legitimate client's identity.

For example, an attacker could register malicious.com that redirects to https://legitimate-client.com/metadata.json, then put "client_id": "https://legitimate-client.com/metadata.json" in the document. If the authorization server matches against the final URL, this would incorrectly validate.

Recommendation

Adding clarification to Section 4.1 Client Metadata:

The client metadata document MUST contain a client_id property whose value MUST match the original client_id URL from the authorization request using simple string comparison as defined in [RFC3986] Section 6.2.1. If HTTP redirects occur during metadata document retrieval, the comparison MUST be performed against the original URL, not the final redirected URL.

This approach ensures that clients cannot use redirects to impersonate other clients or bypass URL-based security policies.

Related Work

• Complements the SSRF redirect limits discussed in Issue #30 by clarifying validation behavior when redirects are followed
• Builds on Aaron's emphasis on exact string matching for security purposes
• Aligns with the principle in Section 6.5 of preventing redirect-based bypass attacks

Implementation Impact

This clarification would help ensure consistent behavior across authorization server implementations and prevent a class of redirect-based impersonation attacks. The requirement is straightforward to implement and doesn't change the core protocol flow.

[ThisIsMissEm]

I thought we had a recommendation in the draft already, but if not, we should probably specify that a Client ID Metadata Document must not be delivered via redirect. That is, the only acceptable response is a 200 http status code. Redirects do indeed cause a security issue here.

[btiernay]

Happy to be corrected, but I didn't see it 🤔

[ThisIsMissEm]

Have opened #46 that just prohibits redirects entirely, which I think is probably the safer option here.