###### Guides

Learn when multi-tenancy is needed, common pitfalls with Firebase Auth, how to implement it in TypeScript, and how Fuego streamlines tenant and user management.

Aug 20, 2025

[#firebase](/content/blog/tag/firebase/index.html) [#auth](/content/blog/tag/auth/index.html) [#multi-tenancy](/content/blog/tag/multi-tenancy/index.html) [#saas](/content/blog/tag/saas/index.html) [#fuego](/content/blog/tag/fuego/index.html)

# Implementing Multi-Tenancy with Firebase Auth

Managing multiple sets of users in a single application is a common requirement in SaaS platforms, B2B solutions, and enterprise applications. Firebase Authentication provides native support for multi-tenancy, but the implementation and ongoing management can be more challenging than it first appears.

In this post, we’ll look at when multi-tenancy is useful, what problems developers usually encounter, how to implement it with TypeScript, and how tools like **Fuego** can simplify the day-to-day management of tenants and their users.

* * *

## Who Needs Multi-Tenancy?

Multi-tenancy allows you to logically separate users into groups (tenants) while still using a single Firebase project. This is particularly useful in cases like:

- **SaaS platforms for businesses**: Each customer organization has its own set of users, isolated from others.
- **Education platforms**: Schools or universities manage their students, teachers, and staff independently.
- **Marketplace apps**: Sellers and buyers might be grouped under different tenants, ensuring their authentication flows remain separated.
- **White-label apps**: One codebase serves multiple clients, each requiring a separate user base.

* * *

## Common Challenges

While Firebase Auth supports tenants, developers often face a few difficulties:

1. **Limited Google Console features**
   - The Firebase console does not provide advanced user search or filtering across tenants.
   - Searching by email only works within a single tenant at a time.
2. **User migration**
   - Moving users from one tenant to another is not straightforward. It requires custom scripts or APIs.
3. **Consistent data handling**
   - Ensuring that authentication and authorization rules align correctly per tenant can be tricky.
4. **Testing and emulators**
   - Setting up tenants in the Firebase Auth emulator is limited and often requires manual configuration.

* * *

## Enabling Multi‑Tenancy (Console quickstart)

Before writing code, turn on multi‑tenancy and create at least one tenant:

1. In **Google Cloud console** go to **Identity Platform → Settings → Security** and click **Allow tenants**. This enables multi‑tenancy and opens the **Tenants** page.
2. Click **Add tenant**, give it a display name (an ID will be generated), and save.
3. For each tenant, configure **sign‑in providers** (email/password, federated IdPs, MFA, etc.). You can also set a **custom domain** if needed.
4. (Optional) Repeat for additional tenants and align your backend rules/claims to be tenant‑aware.

Once enabled and configured, you can select the active tenant in your client by setting `auth.tenantId`.

## Implementing Multi-Tenancy with the **Client SDK** (TypeScript / Web v9)

Identity Platform/Firebase Auth supports multi-tenancy directly from the **client**. The key is setting `auth.tenantId` _before_ you call any sign-in / sign-up method. Note that `tenantId` is **not persisted** across page reloads, so you must set it each time you need it.

### Initialize and select a tenant

```typescript
import { initializeApp } from "firebase/app";
import { getAuth } from "firebase/auth";

const app = initializeApp({
  apiKey: "…",
  authDomain: "YOUR_CUSTOM_DOMAIN", // optional custom domain
});

const auth = getAuth(app);
// Choose the active tenant for the next auth operations
auth.tenantId = "TENANT_ID1";
```

### Email/password sign-up and sign-in

```typescript
import {
  createUserWithEmailAndPassword,
  signInWithEmailAndPassword,
} from "firebase/auth";

// Ensure the intended tenant is selected
auth.tenantId = "TENANT_ID1";

// Sign up (account will belong to TENANT_ID1)
await createUserWithEmailAndPassword(auth, "user@acme.com", "StrongPass#123");

// Sign in
const { user } = await signInWithEmailAndPassword(
  auth,
  "user@acme.com",
  "StrongPass#123",
);
console.log(user.tenantId); // => "TENANT_ID1"
```

### Switching tenants with a single `Auth` instance

```typescript
// Switch to another tenant for subsequent calls
auth.tenantId = "TENANT_ID2";
// Switch back to project-level IdPs (no tenant)
auth.tenantId = null;
```

### Using multiple `Auth` instances (one per tenant)

```typescript
import { initializeApp } from "firebase/app";
import { getAuth } from "firebase/auth";

const app1 = initializeApp(
  {
    /* same config */
  },
  "app_tenant1",
);
const app2 = initializeApp(
  {
    /* same config */
  },
  "app_tenant2",
);

const auth1 = getAuth(app1);
auth1.tenantId = "TENANT_ID1";
const auth2 = getAuth(app2);
auth2.tenantId = "TENANT_ID2";
```

### Custom token sign-in (tenant-aware)

```typescript
import { signInWithCustomToken } from "firebase/auth";

auth.tenantId = "TENANT_ID1";
await signInWithCustomToken(auth, SOME_CUSTOM_TOKEN_FOR_TENANT_ID1);
```

### Password reset and email actions

```typescript
import { sendPasswordResetEmail } from "firebase/auth";

// Make sure the correct tenant is selected, otherwise the email action will fail or target the wrong tenant
auth.tenantId = "TENANT_ID1";
await sendPasswordResetEmail(auth, "user@acme.com");
```

### Federated providers (example: Microsoft with popup)

```typescript
import { OAuthProvider, signInWithPopup } from "firebase/auth";

auth.tenantId = "TENANT_ID1";
const provider = new OAuthProvider("microsoft.com");
const result = await signInWithPopup(auth, provider);
console.log(result.user.tenantId); // "TENANT_ID1"
```

> Tip: after you sign a user in on tenant A, changing `auth.tenantId` later **does not** change `auth.currentUser.tenantId`; the current session remains linked to the original tenant until you sign out.

* * *

## Managing Users in the Google Console

While the Firebase console provides a UI for managing users, its multi-tenant features are limited:

- You must select a specific tenant before viewing users.
- You cannot search for a user across tenants by email address.
- There is no bulk operation support for moving or copying users between tenants.

This means that for anything beyond simple user creation, you’ll need custom scripts—or a dedicated tool.

* * *

## How Fuego Can Help

For developers and teams that actively manage multi-tenant applications, **Fuego** provides a much smoother workflow:

- **Unified User Management**: Browse users across all tenants in one place, without switching views in the Google console.
- **Powerful Search**: Find users by email or UID, even if you don’t remember which tenant they belong to.
- **Bulk Operations**: Copy, move, or export users between tenants, projects, or databases.
- **Migration Support**: Streamline tenant-to-tenant migrations without writing custom scripts.

This means less time fighting the console and more time focusing on your application.

* * *

## Conclusion

Multi-tenancy is essential for many SaaS and enterprise apps, and Firebase Auth provides the foundation to support it. But real-world use quickly reveals gaps in the tooling and console.

By combining the Firebase Admin SDK with a management tool like Fuego, you can implement, maintain, and scale multi-tenant user bases far more effectively.

* * *