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

Web apps as public clients in OAuth2.0 need to save access and refresh tokens in a browser context.

There are [different techniques](https://blog.ropnop.com/storing-tokens-in-browser) to achieve this, but when we consider **security and persistence** (page refresh/tab reopen), there are only two options: http-only secure cookie or Service Worker.

There is performance issue with cookie where it's sent with every request to a domain that set it. Where access token is not needed sometimes and refresh token is not needed **most of the time**. Also, all requests to services that use that access token should be proxied via the same domain.

Service Worker approach has no such issues/limitations as app can decide explicitly when to attach token to a request. But it has two issues currently in comparison to cookie technique:

1. In PoC from the link above token is stored in SW closure, and is lost with browser closing-opening. There could be a storage that is accessible only from SW context (I suppose CacheStorage is shared between page's window and SW, so can't be securely used as-is for this purpose).
2. Token can't be sent (modified) with initial page request (Request.mode === 'navigation'), where e.g. SSR is needed.

I think if those two issues could be solved, Service Worker approach would be the best practice to store access/refresh token.

Sorry if it looks stackoverflowy, I thought to post it in a form of feature request in case I got the aspects correctly. Would be glad to hear if these issues can be resolved by existing technologies.

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

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