Service Worker as secure storage and provider for access token and refresh token

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

There are different techniques 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 (via headers modification) 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.

No repository files or tests are named. Start by reviewing the Service Worker token-storage PoC, CacheStorage access boundaries, and the Request.mode === "navigation" limitation; document whether secure persistence and initial navigation token handling are feasible, with clear browser and security constraints as the definition of done.