In a multi-hop delegation chain, each agent acts as an OAuth client but typically lacks the hardcoded configuration of a traditional app. By design, agents resolve configuration dynamically at runtime, making fetching the CIMD a natural solution. A single compromised CIMD can then affect the entire chain, not just one client.
On Fri, Mar 27, 2026 at 3:27 PM Aaron Parecki <aaron= [email protected]> wrote: > a developer who is trying to avoid hardcoding things into their client > > On Fri, Mar 27, 2026 at 12:24 PM Warren Parad <wparad= > [email protected]> wrote: > >> 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 <nwatson= >>> [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] >> > _______________________________________________ > OAuth mailing list -- [email protected] > To unsubscribe send an email to [email protected] > -- Kieran Sweeney
_______________________________________________ OAuth mailing list -- [email protected] To unsubscribe send an email to [email protected]
