Any change to have a look to this email? Best Regards.
From: "Oliva Fernandez, Jorge" <jorge.olivafernan...@santander.co.uk> Date: Wednesday, 11 January 2023 at 10:43 To: "oauth@ietf.org" <oauth@ietf.org>, "aa...@parecki.com" <aa...@parecki.com>, "da...@alkaline-solutions.com" <da...@alkaline-solutions.com> Subject: draft-ietf-oauth-browser-based-apps doubst about Service Wrokers Hi, I have been studying the draft https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps-12 and more concretely the section "6.4.2. Acquiring tokens from a Service Worker", as this seems to be the recommended and more secure way to manage tokens in a SPA to avoid XSS attacks or token stealing I have been looking for libraries/products that implement this feature, and studying the Service Workers technology to learn how to implement it by ourselves, and I have realized about some issues related with this approach: Issue 1.- In section 6.4.2. says "This makes service workers the most secure place to acquire and store tokens, as an XSS attack would be unable to exfiltrate the tokens." here I think there is a problem, as long as I have been investigating there not exist a persistent and secure place to store data in a Service Worker (aka SW), the options that I have been looking for are: Service Worker global state, or what is the same in a variable at global scope of the `sw.js` file, this is not reliable as the lifetime of a Service Worker is supposed to be short by definition, so if we save the tokens (access token and refresh token) in the SW we cannot trust that will be there for a concrete time, can live some minutes or seconds, this is described in the W3C definition of a SW (about https://www.w3.org/TR/service-workers/#service-worker-lifetime) concretely say "The lifetime of a service worker is tied to the execution lifetime of events and not references held by service worker clients to the ServiceWorker object." so the lifetime is only tied to one event and is not guarantee that this info lives between different events handling, so this is not a persistent storage is very volatile, this is also mentioned and explained in this Stack Overflow topics https://stackoverflow.com/questions/29741922/prevent-service-worker-from-automatically-stopping and https://stackoverflow.com/questions/34775105/what-causes-the-global-context-of-a-service-worker-to-be-reset Cache API or what is the same CacheStorage, is a storage system designed to Cache Request/Response from SW, but this storage is not secure and can be accessed by normal JS code, there is no special security feature attached to it as described in the next W3C issue https://github.com/w3c/ServiceWorker/issues/698, should be considered as secure/private as the Local or Session storage. Web storage API like `localStorage` or `sessionStorage`, in the few libraries that I have found that use SW like for example the firebase one (https://firebase.google.com/docs/auth/web/service-worker-sessions) clearly says that "Tokens are saved in web storage." but this has the same problem as directly use the web storage API without use SW. So the question is, where should be the tokens (access token and refresh token) stored in a Service Worker if this feature doesn't provide any special way to persist data? Issue 2.- Even if it is possible to store securely the tokens in a Service Worker (see point 1) the next sentences don't seems correct/well explained: - "The service worker MUST intercept the authorization code when the authorization server redirects to the application." - "The service worker MUST not transmit tokens, authorization codes or PKCE secrets (e.g. code verifier) to the frontend application." In a normal Authorization Code flow the Client APP will redirect to the AS authorization endpoint so the End-User can interact and provide the identification/authorization data and when everything is ok the AS will redirect back to the Client APP to the redirect_uri, but the SW cannot intercept this redirection, the SW is a `sw.js` file that responds to events when JS code is executed, SW is not something that can be triggered "before" the page load as the lifecycle of an SW is not related with the DOM or windows object, so effectively the Frontend app should parse the authorization code from the `location.href` and pass this information to the SW using a `message` event, so the sentences highlighted above seems to not be correct as the authorization code will be transmitted to the frontend application and the SW cannot intercept the redirect by himself. Best Regards
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
