Philippe: would you expand on your comment: On Wed, Aug 9, 2023 at 11:51 PM Philippe De Ryck < [email protected]> 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 < [email protected]> 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 <[email protected]> > 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 > [email protected] > https://www.ietf.org/mailman/listinfo/oauth > > > _______________________________________________ > OAuth mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/oauth >
_______________________________________________ OAuth mailing list [email protected] https://www.ietf.org/mailman/listinfo/oauth
