Firebase Authentication vs Google Cloud IAM vs Firestore Security Rules: Who Authorizes Which Request Path

1. Why AtlasMart needs three different authorization mental models

AtlasMart has three operations that look similar from the UI but cross different trust boundaries. A customer reads orders/o-9001 directly from a browser. A support agent presses “Refund,” which calls an AtlasMart backend. A nightly worker repairs stale projections. All three eventually touch Firestore, but they do not arrive with the same principal or pass through the same policy engine. Treating them as “authenticated Firestore calls” hides the most important security distinction in the system.

Authentication establishes who a principal is. Authorization decides what that principal may do. Firebase Authentication issues end-user identity tokens. Cloud Firestore Security Rules authorize mobile/web client requests. Google Cloud IAM authorizes privileged server workloads. A backend that accepts an end-user token has two identities in play simultaneously: the caller’s user identity and the backend’s own workload identity.

Learning outcomes

2. The principal map: user identity is not workload identity

Firebase Auth answers “which signed-in user is this?” for client-oriented flows. IAM answers “which Google Cloud principal is this workload operating as?” for privileged server flows. Security Rules can use request.auth.uid and token claims, but an Admin/server Firestore call is not converted into a Rules request just because the backend originally received a Firebase ID token.

3. Build the local trust-boundary lab

{  "name": "atlasmart-firestore-ch14",  "private": true,  "type": "module",  "engines": { "node": ">=22" },  "dependencies": {    "firebase": "12.19.0",    "firebase-admin": "14.4.0"  },  "devDependencies": {    "firebase-tools": "15.30.0",    "@firebase/rules-unit-testing": "5.0.2"  }}

{  "firestore": {    "rules": "firestore.rules",    "indexes": "firestore.indexes.json"  },  "emulators": {    "firestore": { "port": 8080 },    "auth": { "port": 9099 },    "ui": { "enabled": true, "port": 4000 }  }}

mkdir atlasmart-firestore-ch14 && cd atlasmart-firestore-ch14npm init -ynpm install firebase@12.19.0 firebase-admin@14.4.0npm install --save-dev firebase-tools@15.30.0 @firebase/rules-unit-testing@5.0.2# Save firebase.json, firestore.rules and snippets from this chapter.npx firebase-tools@15.30.0 emulators:start   --project demo-atlasmart-firestore   --only firestore,auth

rules_version = '2';service cloud.firestore {  match /databases/{database}/documents {    function signedIn() { return request.auth != null; }    function tenant() { return signedIn() ? request.auth.token.tenantId : null; }    match /profiles/{uid} {      allow get: if signedIn() && request.auth.uid == uid;      allow list: if false;      allow update: if signedIn()        && request.auth.uid == uid        && request.resource.data.uid == resource.data.uid        && request.resource.data.tenantId == resource.data.tenantId        && request.resource.data.diff(resource.data).affectedKeys()             .hasOnly(["displayName", "locale"]);      allow create, delete: if false;    }    match /orders/{orderId} {      allow get: if signedIn()        && resource.data.tenantId == tenant()        && resource.data.customerId == request.auth.uid;      allow list: if signedIn()        && resource.data.tenantId == tenant()        && resource.data.customerId == request.auth.uid        && request.query.limit <= 25;      allow create: if signedIn()        && request.resource.data.tenantId == tenant()        && request.resource.data.customerId == request.auth.uid        && request.resource.data.status == "DRAFT";      allow update, delete: if false;    }    match /refundRequests/{requestId} {      // Clients can create a request; only trusted backend code changes status.      allow create: if signedIn()        && request.resource.data.requestedBy == request.auth.uid        && request.resource.data.status == "REQUESTED";      allow get: if signedIn()        && resource.data.requestedBy == request.auth.uid;      allow list, update, delete: if false;    }    match /{document=**} {      allow read, write: if false;    }  }}

These Rules deliberately deny client-side updates of orders.status. That turns the refund operation into a privileged server action. The rule is not a “backend rule”; it is specifically the mobile/web policy boundary.

import fs from "node:fs";import test, { before, after, beforeEach } from "node:test";import {  initializeTestEnvironment,  assertSucceeds,  assertFails} from "@firebase/rules-unit-testing";import { doc, getDoc, setDoc, updateDoc } from "firebase/firestore";let env;before(async () => {  env = await initializeTestEnvironment({    projectId: "demo-atlasmart-firestore",    firestore: {      host: "127.0.0.1", port: 8080,      rules: fs.readFileSync("firestore.rules", "utf8")    }  });});beforeEach(async () => {  await env.clearFirestore();  await env.withSecurityRulesDisabled(async ctx => {    const db = ctx.firestore();    await setDoc(doc(db, "profiles/u-1001"), {      uid: "u-1001", tenantId: "t-atlas", displayName: "Ava", locale: "en"    });    await setDoc(doc(db, "orders/o-9001"), {      tenantId: "t-atlas", customerId: "u-1001", status: "PAID", totalCents: 12990    });  });});after(async () => env.cleanup());test("client path is constrained by Rules", async () => {  const ava = env.authenticatedContext("u-1001", { tenantId: "t-atlas", role: "customer" }).firestore();  const other = env.authenticatedContext("u-2002", { tenantId: "t-atlas", role: "customer" }).firestore();  await assertSucceeds(getDoc(doc(ava, "orders/o-9001")));  await assertFails(getDoc(doc(other, "orders/o-9001")));  await assertFails(updateDoc(doc(ava, "orders/o-9001"), { status: "REFUNDED" }));});

// Never ship this module to a browser bundle.process.env.FIRESTORE_EMULATOR_HOST = "127.0.0.1:8080";process.env.FIREBASE_AUTH_EMULATOR_HOST = "127.0.0.1:9099";process.env.GCLOUD_PROJECT = "demo-atlasmart-firestore";import { initializeApp } from "firebase-admin/app";import { getAuth } from "firebase-admin/auth";import { getFirestore } from "firebase-admin/firestore";initializeApp({ projectId: "demo-atlasmart-firestore" });export const adminAuth = getAuth();export const adminDb = getFirestore();

import test from "node:test";import assert from "node:assert/strict";import "./backend/admin.js";import { adminDb } from "./backend/admin.js";test("Admin SDK can perform a write forbidden to client Rules", async () => {  const ref = adminDb.doc("orders/o-9001");  await ref.set({    tenantId: "t-atlas",    customerId: "u-1001",    status: "PAID",    totalCents: 12990  });  await ref.update({ status: "REFUNDED" });  const snap = await ref.get();  assert.equal(snap.data().status, "REFUNDED");});// What this proves: the privileged SDK path is not governed by firestore.rules.// What it does NOT prove: production IAM is correct; the emulator does not enforce IAM.

Expected evidence: the owning client can read its own order, another client cannot, and the owning client still cannot mutate status. The Admin path can mutate status despite that client prohibition. This is the local proof that server libraries bypass Security Rules.

4. Authentication failure, rule denial, application denial and IAM denial are different failures

A single “403” dashboard metric is therefore inadequate. AtlasMart should preserve the layer and reason in structured logs so an incident responder can distinguish a malicious user, a rule regression, a missing IAM binding and a broken App Check rollout.

5. Wrong approach: “The user is authenticated, therefore the request is authorized”

A UI might hide the refund button unless role === 'support'. An attacker can still call the endpoint directly. Likewise, a backend might verify an ID token and immediately perform an Admin SDK update. Both approaches authenticate the caller but fail to authorize the requested business action.

export async function verifiedActor(adminAuth, authorizationHeader) {  const prefix = "Bearer ";  if (!authorizationHeader?.startsWith(prefix)) {    throw Object.assign(new Error("UNAUTHENTICATED"), { status: 401 });  }  const idToken = authorizationHeader.slice(prefix.length);  const decoded = await adminAuth.verifyIdToken(idToken);  return {    uid: decoded.uid,    tenantId: decoded.tenantId,    role: decoded.role,    authTime: decoded.auth_time  };}export function authorizeRefund(actor, order) {  if (actor.tenantId !== order.tenantId) {    throw Object.assign(new Error("CROSS_TENANT"), { status: 403 });  }  if (!["support", "admin"].includes(actor.role)) {    throw Object.assign(new Error("ROLE_REQUIRED"), { status: 403 });  }  if (order.status !== "PAID") {    throw Object.assign(new Error("ORDER_NOT_REFUNDABLE"), { status: 409 });  }}

export function auditAuthorization({ correlationId, actor, action, resource, outcome, reason }) {  console.log(JSON.stringify({    event: "authorization_decision",    correlationId,    actorUid: actor?.uid ?? null,    actorTenantId: actor?.tenantId ?? null,    actorRole: actor?.role ?? null,    action,    resource,    outcome,    reason,    // Deliberately omitted: ID token, refresh token, Authorization header,    // service-account private keys, ADC credential material.    at: new Date().toISOString()  }));}

The repair is explicit: verify token → normalize actor → load the minimum authoritative resource → evaluate tenant/role/invariant policy → perform privileged write → record a non-secret authorization decision. Do not log raw bearer tokens to make debugging easier; that turns observability into credential leakage.

6. Edition and mode boundaries

The trust principle survives the product variation: never let a privileged workload credential become an end-user credential, and never assume an end-user token restricts the backend’s Firestore identity automatically.

Verification checklist and cleanup

• Client owner read succeeds; cross-user read fails.
• Client order-status update fails under Rules.
• Admin SDK emulator update succeeds, proving Rules bypass only—not production IAM correctness.
• Application authorization returns a separate 403 reason before privileged write for wrong tenant/role.
• No log line contains a raw JWT, refresh token, service-account key, Authorization header or ADC file.
• Stop emulators to discard state, or restart with a clean data directory before the next exercise.

Production judgment and bridge to Lesson 2

Choose the authorization layer from the request path, not from the collection name. Direct client access is attractive when Rules can express the policy safely. Privileged or cross-resource actions often belong behind a backend, but moving them there increases blast radius because that backend is now an IAM principal with broader database capability. Lesson 2 focuses on containing that blast radius with least-privilege service identities plus mandatory application-layer authorization.

Knowledge check

1. Does verifying a Firebase ID token make an Admin SDK Firestore write obey Security Rules?
2. What does the emulator Admin-bypass test prove?
3. Why is UI button visibility not authorization?
4. Which identity does IAM evaluate for a backend Firestore call?
5. Is MongoDB compatibility simply Native mode with different query syntax?

Summary

AtlasMart now has an explicit principal map. End users authenticate with Firebase Auth, direct client requests meet Security Rules, privileged workloads meet IAM, and backend business authorization bridges the two identities without confusing them.

Authoritative references

• Secure data in Cloud Firestore
• Firestore IAM
• Security Rules conditions and server-library bypass
• Add the Firebase Admin SDK to your server
• Verify Firebase ID tokens
• Custom claims and access control
• Manage user sessions and token revocation
• Connect to the Authentication emulator
• Connect to the Firestore emulator
• How Application Default Credentials works
• Best practices for service accounts
• Workload Identity Federation
• Firestore IAM roles and permissions
• Authenticate and connect with Firestore MongoDB compatibility
• Enterprise Native server client libraries
• Firebase Admin Node.js SDK release notes
• Firebase CLI release notes