How do I store OAuth refresh tokens securely?

Store OAuth refresh tokens like you would a password: minimize exposure, encrypt at rest, restrict access, and make theft less useful.

Best practices

• Use HTTPS/TLS everywhere

  • Never send refresh tokens over plain HTTP.
  • Use secure API endpoints only.

• Store only on the server if possible

  • Prefer keeping refresh tokens in a backend/database, not in a browser or mobile app unless necessary.
  • For web apps, use a backend session or token broker pattern.

• Encrypt tokens at rest

  • Use strong encryption (for example, AES-256) with keys managed separately.
  • Ideally use a KMS/HSM (AWS KMS, GCP KMS, Azure Key Vault, etc.) rather than hardcoding keys.

• Hashing is usually not suitable

  • Unlike passwords, refresh tokens often need to be recovered to exchange for new access tokens, so you usually encrypt them rather than hash them.
  • If you only need to verify a token and never retrieve it, hashing can work, but that’s uncommon for refresh tokens.

• Restrict database and application access

  • Limit who/what can read the token store.
  • Apply least privilege for services, admins, and support tooling.

• Separate secrets from app code

  • Never store refresh tokens in source code, config files, logs, or error messages.
  • Use secret managers for any app credentials or encryption keys.

• Rotate and revoke

  • Support token rotation if the provider allows it.
  • Revoke tokens on logout, password change, suspicious activity, or account deletion.
  • Keep refresh tokens short-lived if the provider supports it.

• Use secure storage on clients

  • Mobile: store in Keychain (iOS) / Keystore (Android).
  • Desktop: use OS credential stores when available.
  • Browser: avoid localStorage/sessionStorage for long-lived refresh tokens if possible; prefer httpOnly, Secure, SameSite cookies or a backend-managed approach.

• Protect against XSS/CSRF

  • If using cookies, mark them HttpOnly, Secure, and appropriately SameSite.
  • Harden your app against XSS because any client-side token storage is vulnerable to script theft.

• Log carefully

  • Never log raw tokens.
  • Redact secrets in traces, analytics, and support dumps.

• Monitor and detect abuse

  • Track token use by device/session/IP heuristics.
  • Alert on unusual refresh frequency, geo anomalies, or impossible travel.

Common secure patterns

1. Backend session + refresh token

   • Client gets a session cookie.
   • Server stores the OAuth refresh token encrypted.
   • Client never sees the refresh token.

2. Mobile app secure enclave/keystore

   • Refresh token stored in OS-provided secure storage.
   • Accessed only by the app.

3. Browser app with BFF (Backend-for-Frontend)

   • Browser talks to your backend via cookies.
   • Backend talks to OAuth provider and stores refresh token securely.

If you want the shortest rule of thumb

• Server-side storage + encryption + KMS + least privilege + rotation
• Avoid exposing refresh tokens to the browser whenever possible.

If you tell me your platform (web SPA, backend app, mobile, desktop), I can give a recommended storage architecture and concrete implementation tips.