token handling Shipped
What this lens looks for
Keep access tokens short-lived (5-15 min) and include only necessary claims — no PII in JWTs that transit untrusted parties. Refresh tokens are longer-lived but bound to the client, use rotation, and are stored server-side when possible. For the refresh strategy, refresh proactively before expiry (e.g., at 75% of TTL), queue concurrent requests during a refresh to avoid race conditions, and retry with backoff on refresh failure. Use the right secure storage per platform: Keychain Services on Apple, EncryptedSharedPreferences or Android Keystore on Android, DPAPI (ProtectedData) on Windows, and HttpOnly Secure SameSite cookies on the web (never localStorage). Never do these: store tokens in localStorage or sessionStorage (XSS-accessible); put tokens in URL query parameters (they leak into server logs, browser history, and referrer headers); use alg: none in JWTs — the alg header must be validated server-side against an allowlist; or trust client-supplied JWT claims for authorization without server-side verification.
What its verifier checks
Access tokens are short-lived (5-15 min) and JWTs carry only necessary claims with no PII for tokens crossing untrusted parties; refresh tokens are client-bound, rotated, and stored server-side where possible; the refresh strategy refreshes proactively before expiry, queues concurrent requests during refresh, and retries with backoff; tokens are stored in the platform-appropriate secure store (Keychain / EncryptedSharedPreferences or Keystore / DPAPI / HttpOnly Secure SameSite cookie); tokens are never in localStorage or sessionStorage; tokens never appear in URL query parameters; alg: none is never accepted and the JWT alg header is validated server-side against an allowlist; client-supplied JWT claims are verified server-side before being used for authorization.