PWA离线重访时安全维持用户身份认证的最优方案咨询
Great question—this is a common pain point for offline-first apps where security and persistence need to work hand in hand. Let’s break down the best practices to address your core requirements while fixing the token storage security gaps you’ve identified.
First, let’s align on what we’re solving:
- Offline login persistence: Maintain authenticated state when the user revisits the app without an internet connection.
- Secure token storage: Avoid the vulnerabilities of using LocalStorage (XSS-prone) or basic Cookies (if not configured properly).
The key here is to split the problem into online authentication (where we rely on server-side security) and offline state validation (where we use secure local storage without exposing sensitive tokens).
1. Online Authentication: Use HttpOnly, Secure Cookies for Refresh Tokens
Forget storing tokens in LocalStorage—this is a major XSS risk. Instead, leverage secure Cookie attributes for your refresh token:
- Mark the cookie as
HttpOnly: Prevents JavaScript from accessing it, eliminating XSS token theft. - Enable
Secure: Ensures the cookie is only sent over HTTPS. - Set
SameSite=StrictorSameSite=Lax: Mitigates CSRF attacks. - For the access token, keep it in memory only (e.g., in your app’s state management like Redux/Vuex or a global variable). This way, it’s never persisted to disk and is cleared when the page closes.
2. Offline Session Persistence: Encrypted Session Metadata in IndexedDB
Since we can’t reach the server offline, we need to store a verified session state locally—but never raw tokens. Here’s the workflow:
- After successful online login, have your backend return a session ID and session expiration timestamp (bind this session ID to the user’s account server-side).
- Generate a symmetric encryption key (e.g., AES-GCM) using the Web Crypto API. Keep this key only in memory (it’s gone when the page closes).
- Encrypt the session ID and expiration timestamp with this key, then store the encrypted blob in IndexedDB.
- When the user opens the app offline:
- Check IndexedDB for the encrypted session data.
- Prompt the user for a PIN, passphrase, or use WebAuthn (biometrics/hardware key) to regenerate the encryption key.
- If decryption succeeds and the session hasn’t expired, restore the authenticated state and load the pre-downloaded IndexedDB data.
- When reconnected, immediately use the HttpOnly refresh token to fetch a new access token, and validate the local session ID against the server. If the session is invalid (e.g., user changed password), clear all local data.
3. Bonus: WebAuthn for Passwordless, Offline-Friendly Authentication
If your use case allows, WebAuthn is the gold standard here—it eliminates token storage risks entirely:
- Users authenticate using biometrics (fingerprint/face) or a hardware key (YubiKey). The private key lives in the device’s secure element, so it can’t be accessed by JavaScript.
- After online authentication, store a hash of the WebAuthn credential ID in IndexedDB (not the raw credential).
- Offline, use the WebAuthn API to verify the user’s credential against the stored hash. If verified, restore the authenticated state.
- This approach is far more secure than any token-based method, as there’s no sensitive token to steal.
- When downloading data to IndexedDB, tag each record with the encrypted session ID (or a hash of it) to ensure only the authenticated user can access their data offline.
- On logout, clear both the HttpOnly refresh token (via server-side endpoint) and the encrypted session data from IndexedDB.
- Set an expiration on your local encrypted session data that matches the server’s session timeout. Even offline, the user will need to re-authenticate once the session expires.
- Implement a strict Content Security Policy (CSP) to reduce XSS risks, which helps protect the in-memory encryption key.
- Periodically sync session state when online: If the server marks the session as invalid (e.g., user revoked access), clear all local session data immediately.
内容的提问来源于stack exchange，提问作者trig518
