So, yes, a client doing something like:
```
const response = fetch("https://app.example/cimd.json";)
const cimd = response.json()
// ...
oauth.authorize({
redirect_uri: cimd.redirect_uris[0]
})
```
Would be bad, due the the `redirect_uri` in the authorization request being
controlled by a remote document would allow an attacker to hijack by hacking
the server serving the cimd.json, there are cases where the client may want to
fetch the CIMD and then use it's data to validate the options passed to an SDKs
`authorize()` method, as to not initiate an OAuth authorization code redirect
if the redirect_uri or other supplied parameters would fail to match against
the client, as to prevent dead-end redirects (if the redirect_uri isn't in the
CIMD then you'll end up at a dead-end on the authorization server, because it
can't redirect back to the application because it doesn't trust the supplied
redirect_uri).
So it is okay for clients to fetch CIMDs for validation, however the parameters
for authorization redirects should always be application supplied (i.e., hard
coded).
— Emelia
> On 27 Mar 2026, at 18:57, Nick Watson <[email protected]>
> wrote:
>
> I can attest that given a large enough pool of clients, any unusual behavior
> you can imagine will be implemented by at least one of them. :)
>
> On Fri, Mar 27, 2026 at 10:52 AM Warren Parad
> <[email protected] <mailto:[email protected]>> wrote:
>> Could you say more about the scenario where this would be likely to happen?
>>
>> On Fri, Mar 27, 2026, 18:38 Bernard Desruisseaux
>> <[email protected]
>> <mailto:[email protected]>> wrote:
>>> While the Client ID Metadata Document is intended to enable authorization
>>> servers to obtain client metadata, it occurred to me that client developers
>>> might be tempted to use their own CIMD as local configuration.
>>>
>>> I think it would be worthwhile to add a paragraph to the Security
>>> Considerations section to discourage that use. A client that relies on the
>>> redirect_uris from its own CIMD could cause authorization servers to send
>>> an authorization code to an attacker-controlled endpoint if the CIMD is
>>> ever compromised, even if the authorization server performs exact redirect
>>> URI matching. The use of PKCE may reduce the impact of authorization code
>>> disclosure, but it does not eliminate the need to protect redirect handling
>>> and related metadata.
>>>
>>> Thanks,
>>> Bernard
>>> _______________________________________________
>>> OAuth mailing list -- [email protected] <mailto:[email protected]>
>>> To unsubscribe send an email to [email protected]
>>> <mailto:[email protected]>
>> _______________________________________________
>> OAuth mailing list -- [email protected] <mailto:[email protected]>
>> To unsubscribe send an email to [email protected]
>> <mailto:[email protected]>
> _______________________________________________
> OAuth mailing list -- [email protected]
> To unsubscribe send an email to [email protected]
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
