| > 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.
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) 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?
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
Hello Christopher,
The wmrm specification use does not require CORS at the authorization endpoint. - Filip 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
------- 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?
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/ ) 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
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
_______________________________________________ OAuth mailing list OAuth@ietf.orghttps://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
|
