Firebase Auth is the right answer for one very specific case: prototyping an app you don’t plan to grow beyond a basic model. For anything else, you’ll eventually hit limitations that weren’t clear when you picked it. Here’s what they are, roughly in the order you’ll find them.
Limitation 1: No true multi-tenancy
Firebase has “tenants” as a concept, but it’s a premium feature and the implementation is limited. You can’t have one user in multiple tenants with different roles. Custom claims are per-user globally, not per-tenant. B2B SaaS with a multi-workspace model hits this wall fast.
Workarounds exist (manage tenants in your own DB, use Firebase for identity only) but they erode the “Firebase handles it all” value prop.
Limitation 2: Custom claims are capped at 1KB
Firebase lets you attach arbitrary claims to a user’s JWT. They’re capped at 1KB total, per user. That sounds like a lot until you try to encode per-workspace roles, feature flags, and permissions. Teams hit the cap around their 5th-10th workspace role structure.
Workaround: store claims in Firestore/your DB, look them up per request. Now you’re doing DB lookups anyway, which was the whole thing Firebase auth was supposed to save you from.
Limitation 3: No native SAML or SCIM on free tier
SAML is available only on the Firebase Identity Platform paid tier. SCIM isn’t supported at all — you’d build your own provisioning layer on top of Firebase. For B2B SaaS with enterprise ambitions, this is a hard blocker.
Limitation 4: User export is painful
Firebase lets you export users, but the format is limited. Password hashes use a Firebase-specific scrypt variant that’s hard to migrate to other systems. Migrating to another auth provider means every user needs a password reset email — a 20-40% retention hit depending on email open rates.
This is (presumably) not intentional lock-in. It’s the practical result.
Limitation 5: Rate limits you can’t raise
Firebase Auth enforces rate limits you cannot tune. For most apps, they’re generous. For apps with unusual patterns (batch user creation, bulk password reset), you hit them. Google’s response is often “restructure your flow to not do that.” Not always feasible.
Limitation 6: No SLA, no enterprise support tier
Firebase is a Google product with no meaningful SLA on the free tier. On the paid Identity Platform, you get uptime guarantees but not the white-glove support that enterprise customers expect. Your customers expecting “you have a support team we can escalate to” are disappointed to find out you’re a ticket in Google’s system.
Limitation 7: UI customization requires building your own
Firebase provides FirebaseUI, a pre-built sign-in UI. It’s fine for prototypes and impossible to deeply customize. Any serious branded login page ends up being built from scratch, calling Firebase APIs directly.
When Firebase Auth is still the right call
- Prototype or MVP where time-to-first-user is the only metric
- Consumer apps where password + Google/Apple/Facebook login is the full scope
- Apps that will live entirely within the Firebase ecosystem forever (Firestore + Cloud Functions + Auth)
- Internal tools where the user model is simple
When to migrate off
- Your product has become B2B or multi-tenant
- Enterprise customers are asking for SSO/SAML
- Your custom claims have ballooned past 1KB
- Your password migration would send tens of thousands of reset emails — migrate now, before the number grows
The pattern: Firebase Auth is a great on-ramp. Plan your exit at the same time you plan the entry.