Re: [OAUTH-WG] WGLC for Browser-based Apps

[Yannick Majoros]

Thanks for taking the time to respond and for the constructive feedback.

Still, there is some initial incorrect point that makes the rest of the
discussion complicated, and partly wrong.

Specifically, §6.4.2.1 says this: *The service worker MUST NOT transmit
tokens, authorization codes or PKCE code verifier to the frontend
application.*

Wording should be refined, but the idea is that the service worker is
to actually restrict authorization codes from even reaching the frontend.
Of course, easier said than done, but that part happens to be quite easy to
implement.

This has further impact on much of the other statements:
*> The main problem with a browser-only client is that the attacker with
control over the client has the ability to run a silent Authorization Code
flow, which provides them with an independent set of tokens*
[...]
*> **The security differences between a BFF and a browser-only app are not
about token storage, but about the attacker being able to run a new flow to
obtain tokens.*
[...]
*> Again, the security benefits of a BFF are not about stoken storage. Even
if you find the perfect storage solution for non-extractable tokens in the
browser, an attacker still controls the client application and can simply
request a new set of tokens. *

Truth is: no, you can't start a new authentication flow and get the
authorization code back in the main thread. I'm talking about the
redirection scenario, which I'm the most familiar with, but it would
probably apply to the "message" one as well (which is new to me and seems
to be ashtoningly legit due to vague "for example" wording in the OAuth2
spec :-) ).

The service worker, according to
https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/fetch_event#description
, just intercepts the authorization code, gets a token, and never sends it
back to the main code.

But don't trust me on my words: what about demonstrating our claims with
actual code, and as such create a shorter, simpler, but more constructive
discussion?

The demonstration in its current form would not lead to a successful
compromise of a good implementation of access tokens handled by a service
worker.

Yannick


Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
phili...@pragmaticwebsecurity.com> a écrit :

> My responses inline.
>
>
> Hi everyone,
>
> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
> further explains that it "details the security considerations and best
> practices that must be taken into account when developing browser-based
> applications that use OAuth 2.0.".
>
> As such, detailing security considerations is important. I share the point
> of view that basing web applications on proven concepts is important. The
> approaches detailed in the document have all their advantages
> and disadvantages.
>
>
> We have discussed the topic of browser-based apps in depth at the OAuth
> Security Workshop last week. I am also working with Aaron Parecki on
> updating the specification to more accurately reflect these advantages and
> disadvantages. Updates will go out in the coming days/weeks, so we more
> than welcome concrete feedback on the content there.
>
> There are 2 main approaches to browser-based applications security. One of
> them is to store security credentials at the frontend. The other one is to
> use cookies and a BFF. Though common practice, there is nothing
> fundamentally more secure about them in a demonstrable way. Different
> approaches, different characteristics and security assumptions. Nobody can
> prove that either approach is better, just that there are different
> concerns.
>
> Handling security in BFFs relies on cookies that cannot be read by the
> javascript application. This mechanism provides some reliable protection
> about the cookie itself that is used as a kind of credential to access
> confidential web resources. It obviously demands some additional layers in
> the flow (proxy or light server). You also need a mechanism to share
> session information, either at the server side, or for example by having
> the cookie itself hold that information. A bigger concern to me is that you
> basically give up standard mechanisms for securing the flow between the
> frontend and the backend: the security between the two is a custom solution
> (based on cookies, in a specific, custom way, this part being in no way
> OAuth or standard). This solves the problem by not using OAuth at all in
> the browser part of the application, basically making the client
> application purely backend. However, the fact that browser-based
> applications cannot be secured with OAuth isn't universally true, and
> strongly depends on one's definition of "secure", and basically comes down
> to what the security issue is.
>
>
> The updated specification will clearly outline the security considerations
> when making the browser-based application a public OAuth client.
>
> *The main problem with a browser-only client is that the attacker with

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Tom Jones]

You can write your code as strong as you wish. You cannot determine if the
code running in the computer is that code running unaltered. ..tom


On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros  wrote:

> Thanks for taking the time to respond and for the constructive feedback.
>
> Still, there is some initial incorrect point that makes the rest of the
> discussion complicated, and partly wrong.
>
> Specifically, §6.4.2.1 says this: *The service worker MUST NOT transmit
> tokens, authorization codes or PKCE code verifier to the frontend
> application.*
>
> Wording should be refined, but the idea is that the service worker is
> to actually restrict authorization codes from even reaching the frontend.
> Of course, easier said than done, but that part happens to be quite easy to
> implement.
>
> This has further impact on much of the other statements:
> *> The main problem with a browser-only client is that the attacker with
> control over the client has the ability to run a silent Authorization Code
> flow, which provides them with an independent set of tokens*
> [...]
> *> **The security differences between a BFF and a browser-only app are
> not about token storage, but about the attacker being able to run a new
> flow to obtain tokens.*
> [...]
> *> Again, the security benefits of a BFF are not about stoken storage.
> Even if you find the perfect storage solution for non-extractable tokens in
> the browser, an attacker still controls the client application and can
> simply request a new set of tokens. *
>
> Truth is: no, you can't start a new authentication flow and get the
> authorization code back in the main thread. I'm talking about the
> redirection scenario, which I'm the most familiar with, but it would
> probably apply to the "message" one as well (which is new to me and seems
> to be ashtoningly legit due to vague "for example" wording in the OAuth2
> spec :-) ).
>
> The service worker, according to
> https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/fetch_event#description
> , just intercepts the authorization code, gets a token, and never sends it
> back to the main code.
>
> But don't trust me on my words: what about demonstrating our claims with
> actual code, and as such create a shorter, simpler, but more constructive
> discussion?
>
> The demonstration in its current form would not lead to a successful
> compromise of a good implementation of access tokens handled by a service
> worker.
>
> Yannick
>
>
> Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
> phili...@pragmaticwebsecurity.com> a écrit :
>
>> My responses inline.
>>
>>
>> Hi everyone,
>>
>> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
>> further explains that it "details the security considerations and best
>> practices that must be taken into account when developing browser-based
>> applications that use OAuth 2.0.".
>>
>> As such, detailing security considerations is important. I share the
>> point of view that basing web applications on proven concepts is important.
>> The approaches detailed in the document have all their advantages
>> and disadvantages.
>>
>>
>> We have discussed the topic of browser-based apps in depth at the OAuth
>> Security Workshop last week. I am also working with Aaron Parecki on
>> updating the specification to more accurately reflect these advantages and
>> disadvantages. Updates will go out in the coming days/weeks, so we more
>> than welcome concrete feedback on the content there.
>>
>> There are 2 main approaches to browser-based applications security. One
>> of them is to store security credentials at the frontend. The other one is
>> to use cookies and a BFF. Though common practice, there is nothing
>> fundamentally more secure about them in a demonstrable way. Different
>> approaches, different characteristics and security assumptions. Nobody can
>> prove that either approach is better, just that there are different
>> concerns.
>>
>> Handling security in BFFs relies on cookies that cannot be read by the
>> javascript application. This mechanism provides some reliable protection
>> about the cookie itself that is used as a kind of credential to access
>> confidential web resources. It obviously demands some additional layers in
>> the flow (proxy or light server). You also need a mechanism to share
>> session information, either at the server side, or for example by having
>> the cookie itself hold that information. A bigger concern to me is that you
>> basically give up standard mechanisms for securing the flow between the
>> frontend and the backend: the security between the two is a custom solution
>> (based on cookies, in a specific, custom way, this part being in no way
>> OAuth or standard). This solves the problem by not using OAuth at all in
>> the browser part of the application, basically making the client
>> application purely backend. However, the fact that browser-based
>> applications cannot be secured with OAuth isn't universally tr

Re: [OAUTH-WG] WGLC for Browser-based Apps

[Yannick Majoros]

Yes, but this is true for all flows. Web applications are dangerous.
Applications handling user input are dangerous too.

Le dim. 27 août 2023, 17:46, Tom Jones  a
écrit :

> You can write your code as strong as you wish. You cannot determine if the
> code running in the computer is that code running unaltered. ..tom
>
>
> On Sun, Aug 27, 2023 at 5:25 AM Yannick Majoros  wrote:
>
>> Thanks for taking the time to respond and for the constructive feedback.
>>
>> Still, there is some initial incorrect point that makes the rest of the
>> discussion complicated, and partly wrong.
>>
>> Specifically, §6.4.2.1 says this: *The service worker MUST NOT transmit
>> tokens, authorization codes or PKCE code verifier to the frontend
>> application.*
>>
>> Wording should be refined, but the idea is that the service worker is
>> to actually restrict authorization codes from even reaching the frontend.
>> Of course, easier said than done, but that part happens to be quite easy to
>> implement.
>>
>> This has further impact on much of the other statements:
>> *> The main problem with a browser-only client is that the attacker with
>> control over the client has the ability to run a silent Authorization Code
>> flow, which provides them with an independent set of tokens*
>> [...]
>> *> **The security differences between a BFF and a browser-only app are
>> not about token storage, but about the attacker being able to run a new
>> flow to obtain tokens.*
>> [...]
>> *> Again, the security benefits of a BFF are not about stoken storage.
>> Even if you find the perfect storage solution for non-extractable tokens in
>> the browser, an attacker still controls the client application and can
>> simply request a new set of tokens. *
>>
>> Truth is: no, you can't start a new authentication flow and get the
>> authorization code back in the main thread. I'm talking about the
>> redirection scenario, which I'm the most familiar with, but it would
>> probably apply to the "message" one as well (which is new to me and seems
>> to be ashtoningly legit due to vague "for example" wording in the OAuth2
>> spec :-) ).
>>
>> The service worker, according to
>> https://developer.mozilla.org/en-US/docs/Web/API/ServiceWorkerGlobalScope/fetch_event#description
>> , just intercepts the authorization code, gets a token, and never sends it
>> back to the main code.
>>
>> But don't trust me on my words: what about demonstrating our claims with
>> actual code, and as such create a shorter, simpler, but more constructive
>> discussion?
>>
>> The demonstration in its current form would not lead to a successful
>> compromise of a good implementation of access tokens handled by a service
>> worker.
>>
>> Yannick
>>
>>
>> Le sam. 26 août 2023 à 14:20, Philippe De Ryck <
>> phili...@pragmaticwebsecurity.com> a écrit :
>>
>>> My responses inline.
>>>
>>>
>>> Hi everyone,
>>>
>>> The document is about "OAuth 2.0 for Browser-Based Apps". Its abstract
>>> further explains that it "details the security considerations and best
>>> practices that must be taken into account when developing browser-based
>>> applications that use OAuth 2.0.".
>>>
>>> As such, detailing security considerations is important. I share the
>>> point of view that basing web applications on proven concepts is important.
>>> The approaches detailed in the document have all their advantages
>>> and disadvantages.
>>>
>>>
>>> We have discussed the topic of browser-based apps in depth at the OAuth
>>> Security Workshop last week. I am also working with Aaron Parecki on
>>> updating the specification to more accurately reflect these advantages and
>>> disadvantages. Updates will go out in the coming days/weeks, so we more
>>> than welcome concrete feedback on the content there.
>>>
>>> There are 2 main approaches to browser-based applications security. One
>>> of them is to store security credentials at the frontend. The other one is
>>> to use cookies and a BFF. Though common practice, there is nothing
>>> fundamentally more secure about them in a demonstrable way. Different
>>> approaches, different characteristics and security assumptions. Nobody can
>>> prove that either approach is better, just that there are different
>>> concerns.
>>>
>>> Handling security in BFFs relies on cookies that cannot be read by the
>>> javascript application. This mechanism provides some reliable protection
>>> about the cookie itself that is used as a kind of credential to access
>>> confidential web resources. It obviously demands some additional layers in
>>> the flow (proxy or light server). You also need a mechanism to share
>>> session information, either at the server side, or for example by having
>>> the cookie itself hold that information. A bigger concern to me is that you
>>> basically give up standard mechanisms for securing the flow between the
>>> frontend and the backend: the security between the two is a custom solution
>>> (based on cookies, in a specific, custom way, this part being in no way
>

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Dick Hardt]

For many resources, the information is already disclosed. What is excessive
to you might be crucial to others -- and my use case, the disclosure is
crucial.

Extrapolating your basis for objecting, that another endpoint provides
additional attack surface, we would not do ANY new endpoints or
functionality since they would all provide more attack surface.

On Sat, Aug 26, 2023 at 11:38 PM Jaimandeep Singh <
jaimandeep.phdc...@nfsu.ac.in> wrote:

> Hi Dick,
>
> My previous emails do not even obliquely refer to security by obscurity.
> It is about design patterns and excessive information disclosure.
>
> Regards
> Jaimandeep Singh
>
> On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt,  wrote:
>
>> Jaimandeep: Do I understand your objection to adoption is that providing
>> a resource discovery endpoint increases the attack surface as an
>> attacker gains knowledge about the resource?
>>
>> If I understand that correctly, then you are suggesting security through
>> obscurity.
>>
>> As mentioned by Aaron, there is no requirement for a resource to support
>> the resource metadata, and the metadata itself could be protected.
>>
>> Practically though, I believe the argument that security is improved by
>> not having a resource discovery endpoint is false. Most resources have
>> publicly available documentation which will contain the same information,
>> and while the docs are not necessarily machine readable, LLMs can make it
>> pretty accessible.
>>
>> Even if you wanted to keep it secret, if applications that use the
>> resource are readily available, how the applications interact with the
>> resource can be discerned through reverse engineering.
>> I think that a security consideration calling out that a malicious actor
>> more readily has access to the protected resource metadata is an adequate
>> response.
>>
>> For my use case, the protected resource metadata is required for the
>> functionality I plan to implement. The AS has no prior knowledge about the
>> protected resource, and when a request is made, the AS learns about the PR
>> and presents the user with an experience based on the metadata for the user
>> to make a decision to grant access.
>>
>> /Dick
>>
>>
>>
>> On Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh > 40nfsu.ac...@dmarc.ietf.org> wrote:
>>
>>> Hi Aaron,
>>>
>>> Thx for your suggestions. I have reviewed the recordings and I would
>>> suggest following:
>>>
>>> 1. Design Consideration: The two components of the OAuth 2.0 ecosystem
>>> authorization server (step 1) and protected resource server (step 2) may
>>> appear independent, but from systems perspective there is a linear
>>> dependency between them. Directly engaging with step 2, even in a limited
>>> capacity, threatens the established sequence and poses substantial security
>>> and architectural implications.
>>>
>>> 2. Information Disclosure: Say I have my HIPPA record stored on a
>>> protected resource server, I don't want any app to even know that I have
>>> such a resource available with a protected resource server in the first
>>> place. The concept of exposing the mere existence of such data raises a
>>> glaring concern. Looking at Google, it has a fine-grained authorization
>>> strategy that meticulously limits access for its RESTRICTED scopes only to
>>> apps that meet certain security benchmarks. Once, the malicious apps come
>>> to know of the prized data at the resource server, it will lead to targeted
>>> phishing attacks, as was highlighted during the 117 meeting, underscoring
>>> the fragility of this approach.
>>>
>>> 3. The Imperative of Gradation and Minimal Exposure: Even if we have to
>>> go down this path, there is a definite need to mitigate the perils of
>>> overexposure. Instead we can look at gradation strategy, wherein the scopes
>>> could be categorized into levels, spanning from generic (Level 0) to
>>> tightly controlled (Level 5) access. There is no requirement of
>>> secondary URI in this appch. For instance, the sensitive scopes like level
>>> 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no
>>> need to divulge if a particular resource is present or not and not even the
>>> address of the authorization server.
>>>
>>> Thanks
>>> Jaimandeep Singh
>>>
>>>
>>> On Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki >> 40parecki@dmarc.ietf.org> wrote:
>>>
 Hi Jaimandeep,

 As with many OAuth extensions, this is not obligatory to implement
 unless you need the functionality it provides. Many of the concerns you
 mention are referenced in the security considerations section of the draft
 already, and we would of course be happy to further expand that section as
 appropriate.

 As we presented during the last two IETF meetings, there are many use
 cases that would benefit from this draft that currently don't have an
 interoperable solution. I would suggest you review those presentation
 recordings so better understand the use cases.

 Aaron
>>>

Re: [OAUTH-WG] Call for adoption - Protected Resource Metadata

[Neil Madden]

Right. It’s worth noting that many endpoints already publish similar metadata via OpenAPI (Swagger) API descriptions.NeilOn 27 Aug 2023, at 19:42, Dick Hardt  wrote:For many resources, the information is already disclosed. What is excessive to you might be crucial to others -- and my use case, the disclosure is crucial. Extrapolating your basis for objecting, that another endpoint provides additional attack surface, we would not do ANY new endpoints or functionality since they would all provide more attack surface.On Sat, Aug 26, 2023 at 11:38 PM Jaimandeep Singh  wrote:Hi Dick,My previous emails do not even obliquely refer to security by obscurity. It is about design patterns and excessive information disclosure.RegardsJaimandeep Singh On Sat, 26 Aug, 2023, 8:27 pm Dick Hardt,  wrote:Jaimandeep: Do I understand your objection to adoption is that providing a resource discovery endpoint increases the attack surface as an attacker gains knowledge about the resource?If I understand that correctly, then you are suggesting security through obscurity.As mentioned by Aaron, there is no requirement for a resource to support the resource metadata, and the metadata itself could be protected. Practically though, I believe the argument that security is improved by not having a resource discovery endpoint is false. Most resources have publicly available documentation which will contain the same information, and while the docs are not necessarily machine readable, LLMs can make it pretty accessible. Even if you wanted to keep it secret, if applications that use the resource are readily available, how the applications interact with the resource can be discerned through reverse engineering. I think that a security consideration calling out that a malicious actor more readily has access to the protected resource metadata is an adequate response.For my use case, the protected resource metadata is required for the functionality I plan to implement. The AS has no prior knowledge about the protected resource, and when a request is made, the AS learns about the PR and presents the user with an experience based on the metadata for the user to make a decision to grant access. /DickOn Fri, Aug 25, 2023 at 8:29 PM Jaimandeep Singh 40nfsu.ac...@dmarc.ietf.org> wrote:Hi Aaron,Thx for your suggestions. I have reviewed the recordings and I would suggest following:1. Design Consideration: The two components of the OAuth 2.0 ecosystem authorization server (step 1) and protected resource server (step 2) may appear independent, but from systems perspective there is a linear dependency between them. Directly engaging with step 2, even in a limited capacity, threatens the established sequence and poses substantial security and architectural implications.2. Information Disclosure: Say I have my HIPPA record stored on a protected resource server, I don't want any app to even know that I have such a resource available with a protected resource server in the first place. The concept of exposing the mere existence of such data raises a glaring concern. Looking at Google, it has a fine-grained authorization strategy that meticulously limits access for its RESTRICTED scopes only to apps that meet certain security benchmarks. Once, the malicious apps come to know of the prized data at the resource server, it will lead to targeted phishing attacks, as was highlighted during the 117 meeting, underscoring the fragility of this approach.3. The Imperative of Gradation and Minimal Exposure: Even if we have to go down this path, there is a definite need to mitigate the perils of overexposure. Instead we can look at gradation strategy, wherein the scopes could be categorized into levels, spanning from generic (Level 0) to tightly controlled (Level 5) access. There is no requirement of secondary URI in this appch. For instance, the sensitive scopes like level 3 and above, may mandate clients to support DPoP and OAuth 2.1. There is no need to divulge if a particular resource is present or not and not even the address of the authorization server.ThanksJaimandeep SinghOn Sat, Aug 26, 2023 at 7:03 AM Aaron Parecki 40parecki@dmarc.ietf.org> wrote:Hi Jaimandeep,As with many OAuth extensions, this is not obligatory to implement unless you need the functionality it provides. Many of the concerns you mention are referenced in the security considerations section of the draft already, and we would of course be happy to further expand that section as appropriate. As we presented during the last two IETF meetings, there are many use cases that would benefit from this draft that currently don't have an interoperable solution. I would suggest you review those presentation recordings so better understand the use cases.AaronOn Fri, Aug 25, 2023 at 12:31 PM Jaimandeep Singh 40nfsu.ac...@dmarc.ietf.org> wrote:I do not support the adoption because of following:1. Increased Attack Surface and Information Disclosure: The p