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
