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

Philippe: would you expand on your comment:

On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <
philippe@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 and
descriptions of using service workers:

https://github.com/ForgeRock/appAuthHelper/blob/master/service_workers.md

https://gaurav-techgeek.medium.com/re-architecting-authentication-with-service-workers-ff8fbbbfbdeb

https://itnext.io/using-service-worker-as-an-auth-relay-5abc402878dd

https://about.grabyo.com/service-workers-jwt-tokens/

On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck <
philippe@pragmaticwebsecurity.com> wrote:

> 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 presentation can spark the necessary discussion to identify a path
> forward to make the RFC useful for practitioners building browser-based
> apps.
>
> I don't have the resources available to write a lengthy email detailing my
> objections. I just want to point out that I've raised these points on the
> mailing list in the past, and there have been a couple of threads on this
> very list suggesting how to move this document forward (e.g., identify
> concrete threat models). I've also given a talk at NDC Security earlier
> this year (https://www.youtube.com/watch?v=OpFN6gmct8c) about how the
> security mechanisms proposed in this document fall short. This video has
> been posted to this list before as well.
>
> Here are a couple of suggestions that I believe would improve this
> document:
>
> - Clearly identify the danger of malicious JS (exfiltrating existing
> tokens is only one threat, and the most trivial one at that)
> - State the baseline achievable level of security in light of existing XSS
> vulnerabilities (i.e., session riding, where the attacker controls the
> frontend)
> - Identify different desired levels of security for a client application
> (e.g., a "public recipe app" vs "eHealth"). Existing work can help, such as
> the OWASP ASVS levels (
> https://github.com/OWASP/ASVS/blob/master/4.0/en/0x03-Using-ASVS.md)
> - Define which levels of security certain mechanisms can offer (e.g., RTR
> for level 1, TMI-BFF for level 2, BFF for level 3)
> - Remove unproven and overly complicated solutions (i.e., the service
> worker approach)
>
> As stated before, I'll be at OSW in London in 2 weeks and would be happy
> to discuss this further.
>
> Kind regards
>
> Philippe
>
> —
> *Pragmatic Web Security*
> *Security for developers*
> https://pragmaticwebsecurity.com
>
> On 30 Jul 2023, at 17:46, Rifaat Shekh-Yusef <rifaat.s.ietf@gmail.com>
> wrote:
>
> 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
> _______________________________________________
> 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
>