Thanks Rifaat,
The editors have just published draft -18 addressing the comments from
Justin Richer's and Andy Barlow's reviews.
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-18.html
Aaron
On Wed, May 1, 2024 at 5:51 AM Rifaat Shekh-Yusef
wrote:
> All,
>
> This is a
All,
This is a *WG Last Call* for the *Browser-Based Apps* draft.
https://datatracker.ietf.org/doc/draft-ietf-oauth-browser-based-apps/
Please, review this document and reply on the mailing list if you have any
comments or concerns, by *May 15. *
If you reviewed the document and you do not have
On Aug 28, 2023, at 9:51 AM, Yannick Majoros wrote:
>
> You really have a point about refresh tokens here, but they are a separate,
> real issue. Refresh tokens should be avoided whenever you can do without. Any
> pattern that can keep them safe is on the same level, but their safety is
>
Hey Aaron,
*> There is a huge difference between being able to access resources
through the user's browser while it's online vs being able to access
resources without the browser's involvement.*
While there are operational differences, the end result is compromission of
the exposed resources for
Hello Philippe,
Thanks for the new details. This new information let me indeed reproduce
the exploit, which seems different from the January one, that I wasn't
able to successfully reproduce against my current implementation.
*> For someone who is more than eager to demand that we prove them
> Again, there is something fundamentally misunderstood here: Philippe's
> exploit will not work with a correctly implemented service worker. Also not
> in an iframe. Also not if you unregister it and you start a new iframe.
For someone who is more than eager to demand that we prove them
That's outside of the responsibility of a BFF. That's what web application
firewalls are doing, with disputable results. They are another tool that
can be used, for any of the described flows btw.
Le lun. 28 août 2023, 18:14, Dick Hardt a écrit :
> While a breach of a BFF may be as catastrophic
While a breach of a BFF may be as catastrophic as an exfiltration of an
access token, the BFF may also be more secure against a breach.
For example, a BFF could detect a possible compromise by the API usage
pattern becoming unusual to the app, that a RS is not able to detect as the
general usage
I agree we should continue to explore service workers — but it does not
seem that using them is a best current practice — and on that basis and
assuming that is correct, I think the SW approach should be dropped from
the document.
On Mon, Aug 28, 2023 at 8:31 AM Yannick Majoros wrote:
> I think
> An XSS compromise would allow an attacker to call the resource server
from the browser context through the BFF, which would lead to the same
catastrophous result as doing it from another context.
There is a huge difference between being able to access resources through
the user's browser while
An XSS compromise would allow an attacker to call the resource server from
the browser context through the BFF, which would lead to the same
catastrophous result as doing it from another context.
Cookies are sent automatically, potentially to resources which shouldn't
get it. Same threat level as
Something is deeply flawed about this thread. Consider that the following
quote from Steiner talks about information in the client as though the
client were actually the client is the resource owner. But the resource
owner should view the client as just another attacker. Somewhere the
interest of
> BFFs are not any safer, XSS or any successful malicious javascript
execution has the same end effect
As described in the draft as well as in this email thread, this is
incorrect.
An XSS compromise of the BFF architecture results in the attacker being
able to make requests to the BFF with the
I think we should discuss facts and demonstrations rather than show and
call to authority. I really want a constructive discussion on this. I'm
perfectly fine with service workers being seen as an unfit solution, if
it's backed by facts and proofs. We've not reached that point.
Le lun. 28 août
Again, there is something fundamentally misunderstood here: Philippe's
exploit will not work with a correctly implemented service worker. Also not
in an iframe. Also not if you unregister it and you start a new iframe.
There is no "need to explain yourself several times" and nobody has
"already
My last comment was rather ironic: user-facing applications are dangerous
(security is hard, which I say nothing with), and that is true for any
scheme.. BFFs are not any safer, XSS or any successful malicious javascript
execution has the same end effect (=game over, complete compromise of
I think, by far, Philippe’s perspective on web security and the threat modeling
of BFF vs SPA based implicit flows is accurate and astute.
His perspective should be the driving force for any standard in this area.
I also think it’s dangerous misinformation to claim that BFF has no security
*applause*
Sucks you need to explain yourself several times but this is very helpful for
the community.
> On Aug 28, 2023, at 7:52 AM, Philippe De Ryck
> wrote:
>
> Responses inline.
>
>> Still, there is some initial incorrect point that makes the rest of the
>> discussion complicated,
Responses inline.
> Still, there is some initial incorrect point that makes the rest of the
> discussion complicated, and partly wrong.
I believe the key to make the discussion less complicated is to acknowledge
that there are two separate issues:
1. An attacker can potentially obtain tokens
I think this is a great discussion, and it seems to me that Yannicks last
comment is basically what Phillippe is trying to point out..
I just wanted to remind the authors about a couple of things that we
briefly discussed during OSW in London.
Although it might not be directly relevant for this
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
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
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
Right Philippe - there really is no way to create a secure client as a web
app. You would need access to the trusted execution environment, which is
not available.
..tom
On Sat, Aug 26, 2023 at 5:21 AM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:
> My responses inline.
>
>
>
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
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
I’m going to respond inline and re-organize the previous message a bit.
> It's worth noting that it didn't get so much traction up to this time, and
> that I stopped using it in multiple applications myself.
That’s exactly what I meant with my statement of an “unproven approach”. If
you, the
Philippe: thanks for investigating each of the links I provided. I had
mistakenly assumed that the SW would be managing the entire OAuth
interaction per the recommendation.
Yannick: thank you for sharing your own experience and views.
It seems that the SW recommendation is aspirational rather
Hello everyone,
I'd like to contribute to the ongoing discussion by sharing my insights.
Giving some feedback has been on my list for a long time, but hasn't been
feasible for me due to time constraints, as I'm sure all of you have. I'm
taking some time to give my two cents.
First, some context.
> I have a different interpretation of the objective of using a service worker,
> and it aligns with descriptions in most of those links -- minimize the risk
> of the access token and refresh token exfiltration from the application by
> malicious JS code. Service workers, when implemented
I have a different interpretation of the objective of using a service
worker, and it aligns with descriptions in most of those links -- minimize
the risk of the access token and refresh token exfiltration from the
application by malicious JS code. Service workers, when implemented
properly,
Hi Dick,
The solutions you list here focus on using a service worker to intercept an
outgoing call to a resource server. During interception, the service worker
attaches the access token. This pattern is mainly used to avoid inserting
access token logic into the application code. The SW
Philippe: would you expand on your comment:
On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <
phili...@pragmaticwebsecurity.com> wrote:
- Remove unproven and overly complicated solutions (i.e., the service
worker approach)
A quick Google on oauth service workers returned a number of articles
Hi Philippe, I look forward to discussing this with you at the OAuth
Security Workshop later this month. Like I mentioned to you last year, I
want to make sure your concerns are adequately captured in the document.
The goal for this draft is not to present the one "best" architecture for
I agree with Philippe here.
If there are already documented attack vectors working around the techniques
presented in this document, then I worry it will give people a false sense of
security if they follow the guidance contained therein.
-Brock
On 8/10/2023 2:51:35 AM, Philippe De Ryck
In my opinion, this document is not ready to be published as an RFC.
In fact, I will be at the OAuth Security Workshop in two weeks to discuss
exactly this (See "The insecurity of OAuth 2.0 in frontends" here:
https://oauth.secworkshop.events/osw2023/agenda-thursday). My hope is that my
All,
This is a *WG Last Call *for the* Browser-based Apps* draft.
https://www.ietf.org/archive/id/draft-ietf-oauth-browser-based-apps-14.html
Please, review this document and reply on the mailing list if you have any
comments or concerns, by *August 11th*.
Regards,
Rifaat & Hannes
37 matches
Mail list logo
