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
