Re: [w3c/ServiceWorker] Service Worker as secure storage and provider for access token and refresh token (Issue #1626)

I would like to second this request.

However, I need to make some notes about the link you provided.
I am focused on the service worker(SW) approach listed in that link.  However, there's currently a draft document talking about the security implications of such an approach (which also rules out all of the other approaches outlined).

# security background
https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-7.4
It discourages the use of SWs as OAuth clients and lists a few reasons.
*  Acquisition and Extraction of New Tokens [Section 5.1.3](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#scenario-new-flow)[¶](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-7.4.1-2.1.1)
* Proxying Requests via the User's Browser [Section 5.1.4](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#scenario-proxy)[¶](https://datatracker.ietf.org/doc/html/draft-ietf-oauth-browser-based-apps#section-7.4.1-2.2.1)

These approaches are made possible if the site itself is compromised. (It's best not to make things worse when something bad happens. In this case, an attacker that has compromised an origin could generate tokens for users at will. That's much worse.)

* 5.1.4 is the same as for cookie based authentication. The document deems that out of scope, so I will as well.
* 5.1.3 is where the magic happens. Since a page can "unregister" a SW, care needs to be made to ensure that the **page** itself cannot perform an authorization flow alone.

The problem is that while the SW can handle these requests and prevent the page from making them, it will be unable to do that in a new window/frame if the SW has been unregistered by malicious code first.

However, if you take a few precautions, this won't be an issue.

1. The IDP should use authentication cookies that are `same-site: lax` or better.
2. The IDP should send headers preventing being framed (X-FRAME-OPTIONS, CSP)
3. The IDP should send a COOP header of `same-site`.
4. The server of the OAuth application should implement the redirect endpoint with a redirect removing the auth code from the url. (The SW, when installed and active, will intercept this redirect)

(1-3) are likely best-practice for any serious IDP implementation.
  1. Will prevent cookies from being sent to the IDP, preventing it from knowing who the user even is.
  2. Will prevent the IDP from rendering framed in the page.
  3. Will force any popup window into a new process and break the connection it had with the opening page.
  4. Will prevent the page from spying on a window or frame to watch the url change and extract the auth_code.
    * Tested in FF and Chrome with a 1 second delay on redirecting the redirect callback request.
      And hammered by polling the window/frame. (ex: /callback?auth_code=asdasfasfd  --1-second-delay--> 302, Location: /does_not_exist ). I was never able to read the intermediate url with the auth_code.

All of these work together to prevent the **page** from initiating an authorization flow and obtaining an authorization code (together with the code_validator can be used to obtain an access and possible refresh token from any machine).

# the ask in this ticket
SWs do not stay active for long.  Tricks to keep the tokens in scopes or globals don't work since they are reset when the SW sleeps and comes back.

You can hang state off of things like self.registration or self.serviceWorker (yuck) but those don't survive SW updates or page reloads.

What is needed is a secure, **private** store for things like tokens that the SW can use to persist information. The page must not have access to this storage. And it would be great if it were encrypted at rest on the filesystem.

The current options we have are all shared: indexedDB, Cache, cookieStore.



-- 
Reply to this email directly or view it on GitHub:
https://github.com/w3c/ServiceWorker/issues/1626#issuecomment-2432975975
You are receiving this because you are subscribed to this thread.

Message ID: <w3c/ServiceWorker/issues/1626/2432975975@github.com>