Which Layer Should Handle Token Refresh in Vue Storefront’s Offline Cache?

Direct Answer

Token refresh belongs in the host application and its API client, not in the Vue Storefront service worker. Treat the service worker as a transport and cache layer; let the application detect authentication failures, coordinate a single refresh call, update IndexedDB, and retry the original request.

Likely Explanation vs. Confirmed Behavior

A service worker can technically read IndexedDB and issue fetches, so centralizing refresh there is tempting. In practice, making it the auth authority creates race conditions: multiple tabs can refresh simultaneously, cached GraphQL responses can be replayed after logout, and cache invalidation becomes coupled to authentication state. The confirmed, safer pattern is to keep orchestration in the host app, where you can enforce a single-flight queue and explicitly invalidate entries.

Least-Privilege Reality Check

Host-app refresh does not inherently break least privilege. The real risks are storage and scope: long-lived refresh tokens in IndexedDB, broad scopes, logging tokens, or blindly retrying non-idempotent mutations after a 401. Use short-lived access tokens, rotated or revocable refresh tokens, minimal scopes, and a single-flight refresh queue. For authenticated GraphQL, prefer network-first or bypass offline caching entirely; cache only public or normalized data offline.

Steps for This Case

1. In the API client, intercept 401 or expired-token responses.
2. If a refresh is already in flight, queue the original request; otherwise call the refresh endpoint once.
3. On success, persist the new credentials to IndexedDB and replay the queued request.
4. On failure or logout, remove auth artifacts and delete affected IndexedDB entries rather than relying on the service worker to infer expiry.
5. Only auto-retry idempotent requests or mutations protected by idempotency keys.

One Diagnostic Detail That Changes Hardening

Is your refresh token JS-readable in IndexedDB, or is it held in an HttpOnly cookie? If it is JS-readable, minimize its lifetime and clear it aggressively. If the backend can set HttpOnly, Secure, and SameSite cookies, the browser can attach credentials without exposing the refresh token to JavaScript; the app still coordinates refresh redirects, but the token never touches IndexedDB.

Version Sensitivity and Verification

Vue Storefront’s offline and service-worker behavior differs by major version, theme, and middleware mode. Before changing auth flow, confirm whether your build uses a custom service worker, a Workbox configuration, or framework-managed caching. In a disposable environment, log only status codes—never tokens—to verify that exactly one refresh call occurs and the original request is retried once. Open two tabs during expiry to ensure the second tab waits for the first refresh. Inspect IndexedDB after logout and after refresh-token revocation to confirm artifacts are removed and not restored on next load. If using cookies, verify the Set-Cookie flags and confirm no refresh token appears in JS-accessible storage.

These recommendations reflect general PWA and Vue Storefront patterns; validate them against your specific version and backend auth contract before production rollout.