Dear All, IMO it is not recommended to add this section because of the following: (a) It is a very specific use case for SPAs or similar design approach and does not warrant mentioning the same in the security BPC as it is further likely to complicate and misrepresent the issue at hand.
(b) It's difficult to appreciate and confusing why CORS SHOULD/MAY be enabled for some endpoints and not recommended for others. (c) It is not appropriate for the BCP, particularly on security matters, to endorse or propose an approach that could compromise security standards. (d) The SPA pattern can be well supported by other mechanisms such as enabling CORS at proxy level if required by the oauth service providers. Regards Jaimandeep Singh On Thu, Mar 9, 2023 at 9:22 PM Jim Manico <j...@manicode.com> wrote: > > 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. > > I would argue that BFF is radically more secure and the SHOULD should > remain or even move to a MUST. Storing high powered access tokens in a > browser is significantly insecure in the face of XSS which very (very) few > applications control well, especially ones that are complex enough to need > OAuth2. > > -- > Jim Manico > @Manicode > > > On Mar 9, 2023, at 3:30 AM, Warren Parad <wparad= > 40rhosys...@dmarc.ietf.org> wrote: > > > It requires third party cookies which most browsers block by default, and > doesn't this assume that the cookie is set to *SameSite=Loose *or > *SameSite=None*. Wouldn't that directly expose that cookie for malicious > sites to utilize it to steal connect2Id generate access tokens? > > Also what I don't understand from the connect2id site is: > >> Performing the redirection in a hidden iframe doesn't normally work for >> an SPA either. > > > Why does it say that? (I feel like it drops this little bomb in there and > then runs away. maybe there is a specific reason, but if there is it is > lost on me) > > On Thu, Mar 9, 2023 at 12:13 PM Dmitry Telegin <dmitryt= > 40backbase....@dmarc.ietf.org> wrote: > >> Hi all, >> >> In regards to the use cases for CORS in the Authorization endpoint - what >> about a SPA requesting a step-up reauthentication? Especially if it is >> "silent", e.g. initiating out-of-band authentication without the need for >> user interaction. Currently, we don't have too many options; it's either a >> full redirect + app reload (not so good from the UX point of view) or a >> (hidden) iframe. Probably deserves a separate discussion? >> >> On a related note, Connect2ID seems to be the only IAM solution that >> offers limited support for CORS in the Authorization endpoint (prompt=none >> + response_mode=cors). The use case they're supporting is silent refresh in >> the absence of a long-lived refresh token. See link: >> https://connect2id.com/products/server/docs/guides/cors-response-mode >> >> Also, it has been mentioned that "CORS on the authorization endpoint is a >> security issue" - could we elaborate on that? What would be the >> ramifications of having it? >> >> Cheers, >> Dmitry >> >> On Thu, Mar 9, 2023 at 9:23 AM Filip Skokan <panva...@gmail.com> wrote: >> >>> Hello Christopher, >>> >>> The wmrm specification use does not require CORS at the authorization >>> endpoint. >>> >>> - Filip >>> >>> 9. 3. 2023 v 10:12, Christopher Burroughs <chris.burroughs= >>> 40protonmail...@dmarc.ietf.org>: >>> >>> >>> Greetings, >>> >>> I apologize in advance if this question (my first in this list!) is >>> silly :) >>> >>> Regarding CORS support for the authorization endpoint, what about "web >>> message" silent refresh flows? While it never became an RFC, I reckon it is >>> implemented in quite a few places. Is this pattern generally discouraged >>> now? Perhaps even more due to the unavailability of same site cookies? >>> >>> Thanks for the interesting discussions, >>> >>> Best regards, >>> Chris >>> >>> >>> Sent with Proton Mail <https://proton.me/> secure email. >>> >>> ------- Original Message ------- >>> On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci <vittorio= >>> 40auth0....@dmarc.ietf.org> wrote: >>> >>> 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 >>> >>> _______________________________________________ >>> 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 >> > _______________________________________________ > 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 > -- Regards and Best Wishes Jaimandeep Singh LinkedIn <http://www.linkedin.com/in/jaimandeep-singh-07834b1b7>
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
