Ha, we chatted about this during yesterday's office hours meeting and I was chartered to propose new language, but I am not sure how to incorporate this new info. Let me try to summarize here and see your reactions, DW. Apps implemented in SPAs style can either handle token acquisition and renewal from the user agent code, via classic authorization code + PKCE, or delegate that to a backend (BFF or "TMI BFF") while retaining "SPA style" for every other app function (eg UX). CORS is required only for the former approach, and one could argue that the latter offers better security. We can either expand on that nuance, or more simply switch the SHOULD to MAY so that we inform the reader of what it takes to support (a style of SPA) but we don't appear to be advocating for the less secure option.
On CORS for the authorization endpoint. I thought the MUST NOT was aimed at preventing programmatic access to the authorization endpoint from user agents. Flipping around: are there any *other* scenarios involving the authorization endpoint for which CORS support enables valid use cases? On Wed, Mar 8, 2023 at 10:50 AM David Waite <david= 40alkaline-solutions....@dmarc.ietf.org> wrote: > *This message originated outside your organization.* > > ------------------------------ > > I would suggest SHOULD guidance for CORS for OAuth token endpoints and > authorization endpoints which are publicly accessible. > > There are a lot of misconceptions about the security properties of CORS, > and in particular the security properties from disabling CORS for an > otherwise safe resource. To my knowledge there is one benefit of disabling > for solely internally-facing infrastructure. > > To detail, a public website interacting with a user agent bridging public > and private networks can use IPs and DNS to attempt to scan internal web > infrastructure. It may attempt to manipulate browser-accessible resources > via GET/POST, and get some information on the shape of the network via > error and timing-based analysis. Enabling or disabling CORS does not affect > reachability for GET/form POST requests (which do not require CORS > preflight), but does affect visibility of the response. > > In such an environment, having CORS enabled for a metadata resource might > reveal additional information to an attacker - such as purpose of a > particular system, and possibly the author/vendor of a particular product. > Note that they may be able to get this from other heuristics of that > product as well, through analysis of other GET/POST requests (such as to > vendor-specific endpoints). > > There is an incubated effort ( > https://wicg.github.io/local-network-access/ > <https://urldefense.com/v3/__https://wicg.github.io/local-network-access/__;!!PwKahg!76HmCyMyQavm5j-6pTSkGFl4O3h1x_tU9APEfd-sc8v8Pes4MMwX04xkxX2MWAkwT4gQj_w60r_mlm1DVz_gAjIMXageTnA$> > ) > which has rather good introductory/explainer text for this class of issue. > I believe Chrome has partially implemented (targeting roll out in 113) - I > do not know other browser intention or status. As currently documented, > this would effectively block API access across public and internal/private > network ranges without a CORS pre-flight and a new pre-flight response. If > adopted by other browsers, this provides a stronger ability to give SHOULD > guidance for CORS, without distinctions between public and internal/private > infrastructure. > > -DW > > On Mar 8, 2023, at 8:36 AM, Aaron Parecki <aaron= > 40parecki....@dmarc.ietf.org> wrote: > > Since that is my comment referenced in the OpenID thread, I should clarify > that my intent was to have this language in the Security BCP with the > caveat that it's only applicable if your AS intends on supporting SPAs. In > other words, we're not saying all ASs SHOULD add CORS headers, only ASs > that intend on supporting SPAs. However, even if the AS does not intend on > supporting SPAs, it still MUST NOT enable CORS at the authorization > endpoint. > > I don't know the best language to put in front of Mike's suggested text to > make that clear, so suggestions are welcome. > > Aaron > > > On Tue, Mar 7, 2023 at 11:16 PM Mike Jones <Michael.Jones= > 40microsoft....@dmarc.ietf.org> wrote: > >> I propose adding the following section to the OAuth Security BCP >> specification: >> >> >> >> *Usage of CORS* >> >> >> >> The Token Endpoint, >> >> Authorization Server Metadata Endpoint, >> >> <spanx style="verb">jwks_uri</spanx> Endpoint, >> >> Dynamic Client Registration Endpoint, >> >> and any other endpoints directly accessed by Clients >> >> SHOULD support the use of >> >> <xref target="CORS">Cross-Origin Resource Sharing >> (CORS)</xref> >> >> to enable JavaScript Clients and other browser-based >> Clients to access them. >> >> CORS MUST NOT be used at the Authorization Endpoint >> >> as it is redirected to by the client and not directly >> accessed. >> >> >> >> >> >> Relevant background information can be found at >> https://bitbucket.org/openid/connect/issues/980 >> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/issues/980__;!!PwKahg!76HmCyMyQavm5j-6pTSkGFl4O3h1x_tU9APEfd-sc8v8Pes4MMwX04xkxX2MWAkwT4gQj_w60r_mlm1DVz_gAjIMNv-T0eA$> >> and >> https://bitbucket.org/openid/connect/pull-requests/338/errata-specified-the-use-of-cors-at >> <https://urldefense.com/v3/__https://bitbucket.org/openid/connect/pull-requests/338/errata-specified-the-use-of-cors-at__;!!PwKahg!76HmCyMyQavm5j-6pTSkGFl4O3h1x_tU9APEfd-sc8v8Pes4MMwX04xkxX2MWAkwT4gQj_w60r_mlm1DVz_gAjIM9UER3uA$> >> . >> >> >> >> -- Mike >> >> >> _______________________________________________ >> OAuth mailing list >> OAuth@ietf.org >> https://www.ietf.org/mailman/listinfo/oauth >> <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!76HmCyMyQavm5j-6pTSkGFl4O3h1x_tU9APEfd-sc8v8Pes4MMwX04xkxX2MWAkwT4gQj_w60r_mlm1DVz_gAjIMa2CknSg$> >> > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth > <https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/oauth__;!!PwKahg!76HmCyMyQavm5j-6pTSkGFl4O3h1x_tU9APEfd-sc8v8Pes4MMwX04xkxX2MWAkwT4gQj_w60r_mlm1DVz_gAjIMa2CknSg$> > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
