Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[David Waite]

> On Mar 9, 2023, at 11:00 AM, Jaimandeep Singh 
>  wrote:
> 
> 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.

The simplest answer is that if it is a user interaction endpoint which may 
leverage browser-integrated state mechanisms (cookies, local storage), then 
CORS SHOULD NOT be enabled for security reasons. SHOULD guidance means they 
still can, but they should have justification for doing so. I can say from 
previously investigating the delta for making a pre-existing authorization 
endpoint CORS-safe that I believe it would be very challenging to do safely.

For API endpoints which take and return requests without using 
browser-integrated state mechanisms, CORS enables a class of client usage. 
Disabling CORS only provides security benefits in that it (somewhat 
accidentally) deters user-bridged network introspection. There is effort 
incubated in the W3C to provide explicit protections for this scenario.

I don’t think any of these guiding rules are OAuth specific - instead, I think 
the industry has done a terrible job explaining CORS to developers and to 
integrators.

> (c) It is not appropriate for the BCP, particularly on security matters, to 
> endorse or propose an approach that could compromise security standards.

The section is server security guidance based on the current state of browsers 
(which are the only clients which care about or respect CORS). The vast 
majority of OAuth interactions involve a browser user agent in some capacity. I 
would expect the Security BCP to be _the_ place to give guidance.

> (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.

Exactly. Setting or unsetting CORS does not restrict SPAs from being possible, 
as they can leverage BFF-style proxies to ignore CORS-based API restrictions, 
or even pure reverse proxies for the token endpoint that hand the access and 
refresh token back to javascript.

Leaving CORS disabled on public-facing server API provides no server security 
benefit in itself, it just artificially and ineffectually restricts a class of 
clients.

I think we do the industry a disservice by not explaining the security and 
interoperability value to implementers/integrators, which is why I think such a 
section is justified - it is certainly a case where people may commonly deviate 
from best current practice. The actual guidance is an orthogonal issue.

-DW
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[David Waite]

> On Mar 9, 2023, at 1:57 AM, Vittorio Bertocci 
>  wrote:
> 
> 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? 

It is challenging because we typically overload a single endpoint with new 
behavior, rather than create new ones for specific purposes. This gives odd 
permutations, such as implementations which conditionally block frame 
embedding, except when prompt=none. It also makes it very difficult to make 
generalizations.

For the currently defined extensions that I know of, there is not a good reason 
to enable CORS - rather, CORS would be harmful without additional security 
requirements.

The clearest example of CORS interaction would be programmatically driving 
authorization experience. I would argue user-facing content which is driving 
authorization actually _is_ the authorization endpoint, and whatever API it is 
interacting with (whether standardized or not) should not be exposed via the 
authorization endpoint.

A second example would be to invoke an authorization decision programmatically 
with out-of-band user interaction. The associated work with this sort of need 
is CIBA, which defined a separate backchannel_authentication_endpoint.

-DW___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Jaimandeep Singh]

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  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  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  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  wrote:
>>
>>> Hello Christopher,
>>>
>>> The wmrm specification use does not require CORS at the authorization
>>> endpoint.
>>>
>>> - Filip
>>>
>>> 9. 3. 2023 v 10:12, Christopher 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  secure email.
>>>
>>> --- Original Message ---
>>> On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci >> 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 secu

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Jim Manico]

> 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@ManicodeOn Mar 9, 2023, at 3:30 AM, Warren Parad  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 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-modeAlso, 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,DmitryOn Thu, Mar 9, 2023 at 9:23 AM Filip Skokan  wrote:Hello Christopher,The wmrm specification use does not require CORS at the authorization endpoint. - Filip9. 3. 2023 v 10:12, Christopher 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 secure email.



--- Original Message ---
On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci 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 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 info

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Warren Parad]

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  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  wrote:
>
>> Hello Christopher,
>>
>> The wmrm specification use does not require CORS at the authorization
>> endpoint.
>>
>> - Filip
>>
>> 9. 3. 2023 v 10:12, Christopher 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  secure email.
>>
>> --- Original Message ---
>> On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci > 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 > 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 infor

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Dmitry Telegin]

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  wrote:

> Hello Christopher,
>
> The wmrm specification use does not require CORS at the authorization
> endpoint.
>
> - Filip
>
> 9. 3. 2023 v 10:12, Christopher 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  secure email.
>
> --- Original Message ---
> On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci  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  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/
>> 
>> ) 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 inte

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Filip Skokan]

Hello Christopher,The wmrm specification use does not require CORS at the authorization endpoint. - Filip9. 3. 2023 v 10:12, Christopher Burroughs :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 secure email.



--- Original Message ---
On Thursday, March 9th, 2023 at 16:57, Vittorio Bertocci  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 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/ ) 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.-DWOn Mar 8, 2023, at 8:36 AM, Aaron Parecki 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.AaronOn Tue, Mar 7, 2023 at 11:16 PM Mike 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,  jwks_uri Endpoint,  Dynamic Client Registration Endpoint,  and any other endpoints directly accessed by Clients  

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Christopher Burroughs]

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 
 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 
>  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 
>>>  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 
>>>  wrote:
>>>
 I propose adding the following section to the OAuth Security BCP 
 specification:

 Usage of COR

Re: [OAUTH-WG] Proposed OAuth Security BCP text on the use of CORS

[Vittorio Bertocci]

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  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/
> 
>  )
> 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  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  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,
>>
>>   jwks_uri Endpoint,
>>
>>   Dynamic Client Registration Endpoint,
>>
>>   and any other endpoints directly accessed by Clients
>>
>>   SHOULD support the use of
>>
>>   Cross-Origin Resource Sharing
>> (CORS)
>>
>>   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.