Firebase Rate Limit & Auth Errors: Fix 401, 403, 429, 502, 503, Token Expired

Understanding Firebase Rate Limit and Auth Errors

Firebase surfaces errors across two distinct layers: the Authentication service (identity tokens, sign-in methods) and the backend services (Firestore, Realtime Database, Cloud Functions, Storage). Each layer has its own quota system, and a failure in one often cascades into errors that look like auth problems in another.

The most common error messages developers encounter:

FirebaseError: Request had invalid authentication credentials. Expected OAuth 2 access token, login cookie or other valid authentication credential. Got 'null'.
FirebaseError: PERMISSION_DENIED: Missing or insufficient permissions.
POST https://identitytoolkit.googleapis.com/v1/accounts:signInWithPassword 400
FirebaseError: TOO_MANY_REQUESTS
[auth/network-request-failed] A network error occurred
HTTP 401 Unauthorized
HTTP 403 Forbidden
HTTP 429 Too Many Requests
HTTP 502 Bad Gateway
HTTP 503 Service Unavailable

Step 1: Identify the Error Layer

Before fixing anything, determine whether the error originates from Firebase Authentication or a downstream service (Firestore, Functions, Storage).

Check the Firebase Authentication service status:

https://status.firebase.google.com

In your browser console or server logs, look at the full request URL in the failed response:

• identitytoolkit.googleapis.com → Authentication layer
• firestore.googleapis.com → Firestore
• cloudfunctions.net or run.app → Cloud Functions
• storage.googleapis.com → Firebase Storage

Extract the error code programmatically:

try {
  await signInWithEmailAndPassword(auth, email, password);
} catch (error) {
  console.error('Code:', error.code);       // e.g. 'auth/too-many-requests'
  console.error('Message:', error.message); // Human-readable
}

Common error.code values and their root causes:

Step 2: Fix Token Expiration (401 / auth/id-token-expired)

Firebase ID tokens expire after 60 minutes. The Firebase SDK auto-refreshes them — but only if you use onAuthStateChanged correctly. Calling getIdToken() without the forceRefresh flag returns the cached (possibly expired) token.

Wrong approach (uses stale token):

const token = await user.getIdToken(); // May return expired token from cache

Correct approach:

// Force refresh when token is near expiry
const token = await user.getIdToken(true); // Forces network call to refresh

// Better: use an Axios interceptor to auto-refresh on 401
axios.interceptors.response.use(
  response => response,
  async error => {
    if (error.response?.status === 401) {
      const user = auth.currentUser;
      if (user) {
        const freshToken = await user.getIdToken(true);
        error.config.headers['Authorization'] = `Bearer ${freshToken}`;
        return axios(error.config); // Retry with new token
      }
    }
    return Promise.reject(error);
  }
);

Server-side token verification (Node.js Admin SDK):

const admin = require('firebase-admin');

async function verifyToken(idToken) {
  try {
    const decoded = await admin.auth().verifyIdToken(idToken);
    return decoded;
  } catch (error) {
    if (error.code === 'auth/id-token-expired') {
      // Token expired — client must refresh
      throw new Error('TOKEN_EXPIRED');
    }
    if (error.code === 'auth/argument-error') {
      // Malformed token — do not retry
      throw new Error('INVALID_TOKEN');
    }
    throw error;
  }
}

Step 3: Fix Rate Limiting (429 / TOO_MANY_REQUESTS)

Firebase enforces rate limits at multiple levels:

• Authentication: 100 sign-up/sign-in requests per IP per minute (adjustable in console)
• Firestore: 1 write per second per document; 10,000 writes per second per database on Blaze plan
• Cloud Functions: 3,000 concurrent executions on Blaze; automatic scale-up with cold start latency

Implement exponential backoff with jitter:

async function withRetry(fn, maxRetries = 5) {
  for (let attempt = 0; attempt <= maxRetries; attempt++) {
    try {
      return await fn();
    } catch (error) {
      const isRateLimit = 
        error.code === 'resource-exhausted' || 
        error.status === 429 ||
        error.message?.includes('TOO_MANY_REQUESTS');
      
      if (!isRateLimit || attempt === maxRetries) throw error;
      
      // Exponential backoff: 1s, 2s, 4s, 8s, 16s + jitter
      const base = Math.pow(2, attempt) * 1000;
      const jitter = Math.random() * 1000;
      await new Promise(resolve => setTimeout(resolve, base + jitter));
    }
  }
}

// Usage
await withRetry(() => setDoc(doc(db, 'users', uid), data));

Use Firestore batch writes to reduce operation count:

const batch = writeBatch(db);

users.forEach(user => {
  const ref = doc(db, 'users', user.id);
  batch.set(ref, user); // Counts as 1 write regardless of batch size
});

await batch.commit(); // Single network round-trip, up to 500 docs

Step 4: Fix Permission Denied (403 / PERMISSION_DENIED)

A 403 means your Security Rules rejected the request. This is not the same as being unauthenticated — a logged-in user can still receive 403 if rules don't allow the operation.

Test rules without deploying using the Rules Playground:

1. Firebase Console → Firestore → Rules → Rules Playground
2. Set Auth UID to your test user's UID
3. Simulate the exact read/write path

Common Firestore rules mistakes:

// BAD: Allows read but denies write — often confused with auth error
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      // Missing write rule defaults to DENY
    }
  }
}

// GOOD: Explicit rules with ownership check
rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow read: if request.auth != null;
      allow write: if request.auth != null && request.auth.uid == userId;
    }
  }
}

Validate rules with the Firebase CLI:

npm install -g firebase-tools
firebase login

# Test rules locally before deploying
firebase emulators:start --only firestore

# Deploy rules
firebase deploy --only firestore:rules

Step 5: Fix 502 / 503 / Connection Refused

HTTP 502 (Bad Gateway) and 503 (Service Unavailable) from Firebase are almost always transient infrastructure issues or Cloud Functions problems.

For Cloud Functions 503 / connection refused:

# Check function logs for timeout or memory errors
firebase functions:log --only myFunction

# Increase timeout and memory in function definition
exports.myFunction = functions
  .runWith({ timeoutSeconds: 300, memory: '512MB' })
  .https.onRequest(async (req, res) => {
    // ...
  });

Reduce cold start latency with minimum instances:

exports.criticalApi = functions
  .runWith({ minInstances: 1 }) // Keeps 1 instance warm
  .https.onRequest(handler);

Test connectivity to Firebase endpoints:

curl -I https://firestore.googleapis.com
curl -I https://identitytoolkit.googleapis.com
nslookup firestore.googleapis.com