> 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.
It is not just the use of a service worker that matters, it is the way the service worker is deployed. The examples you gave earlier all use a service worker to attach a token to an outgoing request. They still obtain the token from the main application (see [1] at the bottom), so tokens are still exposed to the main application. So if the goal is to prevent token exfiltration from the main app, this setup is not effective. The attacker could just run a new flow in an iframe, obtain fresh tokens and exfiltrate them. The proposal of using service workers in this draft aims to provide this security by also shielding the authorization code and token exchange. I have not seen a practical implementation of this pattern. Furthermore, even if you implement this, an attacker with XSS capabilities can still unregister the worker and then obtain tokens to exfiltrate. > 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? Yes, that is exactly why it is not possible to prevent token exfiltration when malicious JS runs. The BFF pattern as described in this document reduces the impact to its minimum level: a session riding attack. In that scenario, the attacker will never be able to obtain access/refresh tokens, and can only “tunnel” requests through the user’s online browser. That’s also why I always recommend to focus on defending against malicious JS instead of just trying to hide tokens. However, history shows that even with the best efforts, malicious JS will eventually end up in the application. Unfortunately, the spec in its current from argues that techniques like refresh token rotation or the service worker help prevent abuse in case of token exfiltration. Since these techniques can (easily) be circumvented, they create a false sense of security. I clearly demonstrate this in the video I referenced earlier (https://www.youtube.com/watch?v=OpFN6gmct8c), as well as in this older post (https://mailarchive.ietf.org/arch/msg/oauth/s68mcQCC1NNe_Y2Q9Qu6x0VuLrI/). Note that this post is more than 3 years old, so my insights and way of explaining has changed since then. > 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? I fully understand that watching a video is not the most straightforward way of consuming content, but in this case, the video adds a tremendous amount of value. It allows me to use graphics to explain the issues, and it includes actual demo attacks to obtain tokens, even with recommended security mechanisms in place. If you would be arguing a point and refer to a video that clearly explains your thoughts, I would definitely watch it. [1] >>> 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 No mention of how tokens end up in the worker. A brief look at the code mentions frames and seems to refer to the AppAuth library, so this does not seem to happen in the worker. >>> https://gaurav-techgeek.medium.com/re-architecting-authentication-with-service-workers-ff8fbbbfbdeb The tokens are obtained from the main application. See the section "Now let us get the right token." >>> https://itnext.io/using-service-worker-as-an-auth-relay-5abc402878dd The tokens are obtained from the main application. I quote: getAuthTokenHeader method will communicate with js executed in a page to get current token >>> https://about.grabyo.com/service-workers-jwt-tokens/ No mention of how tokens end up in the worker.
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
