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
