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, isolate the access token, refresh token, PKCE from code in the DOM, similar to how properly created cookies are isolated from the DOM JS.
This lowers the security risk of using OAuth to protect a server's resources to be similar to the risks of using cookies. I think this is an improvement in the security of the application, and does not create a false sense of security as you claim. If an attacker has the ability to run malicious JS code in the application's origin, the attacker can do anything against the underlying web resources regardless of using OAuth or cookies. Do you have an alternative approach to isolating the OAuth credentials from the DOM code? FWIW: If you want someone to understand previous posts, I'd suggest providing a link to the post, and even better also include a small extract. Also, while it is more effort on your part, I find concise, crisp responses more constructive for email dialog, and similarly, don't expect that the email list has, or will, take the time to watch your video. Have you watched any of mine? On Thu, Aug 10, 2023 at 10:11 PM Philippe De Ryck < phili...@pragmaticwebsecurity.com> wrote: > 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 attaches the > access token, and if it has a refresh token, it can even run the RT flow to > get a new access token. > > Note that the SW is used for convenience here, not for security. The > Browser-Based Apps draft recently added a SW pattern as a security > mechanism (section 6.4.2). The idea is that the SW not only augments calls > to the RS, but also handles the communication with the authorization > server. > > Based on my understanding, this pattern was specifically added to address > an attack scenario I have described a while ago on this mailing list (and > also demonstrate in the video linked in my previous mail). In this > scenario, the attacker has the ability to run malicious JS code in the > application’s origin. The attacker uses that ability to run a silent > Authorization Code flow in an iframe, extracts the code, and exchanges it > for a new set of tokens. > > The SW pattern in the spec aims to prevent the application from calling > the AS directly, since all calls would be intercepted by the SW. This > approach is ineffective, since an attacker can always unregister an > existing service worker. The spec states that an unregistered worker > remains active until the browsing context reloads (after which it would > re-register the worker before the attacker’s code runs). However, after > unregistering a worker, new contexts will no longer use this worker. As > demonstrated in the video I linked to before, an attacker can unregister a > worker and then run a flow in a frame without involving the worker. > > In essence, it boils down to Brock’s statement of “a false sense of > security”. While someone may view this as sufficiently secure for their > specific use cases, I really object to having this as one of the > “recommended approaches” in an RFC. > > Hope this helps > > Philippe > > > On 11 Aug 2023, at 02:56, Dick Hardt <dick.ha...@gmail.com> wrote: > > > 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 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 < > phili...@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.i...@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 >> > >
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
