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]
