What might cause a client to decide it needed to fetch it's own CIMD?
On Fri, Mar 27, 2026 at 7:52 PM Emelia S. <emelia=
[email protected]> wrote:
> 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 <wparad=
> [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 <bernard.desruisseaux=
>> [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]
>>> To unsubscribe send an email to [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]
>
>
>
_______________________________________________
OAuth mailing list -- [email protected]
To unsubscribe send an email to [email protected]
