Firebase on the Server: Node, Python, Django and Laravel

Firebase has two families of SDK, and confusing them is the source of most server-side Firebase problems.

What the Admin SDK is for

Four jobs, mainly:

• Verifying ID tokens. Your app sends a token; your server checks it is genuine before trusting who the user claims to be.
• Privileged writes. Updating data the user must not be able to change directly — order status, credit balances, roles.
• Custom claims. Attaching roles to users, which then appear inside their ID token and can be checked in security rules.
• Bulk work. Migrations, exports, scheduled cleanups — anything that would be far too many operations for a client.

Verifying a token — the pattern that matters most

If your server takes a user ID from the request body, anyone can send any user ID. The correct pattern is to send the ID token and verify it.

import { initializeApp, cert } from "firebase-admin/app";
import { getAuth } from "firebase-admin/auth";

initializeApp({ credential: cert(serviceAccount) });

export async function requireUser(req) {
  const header = req.headers.authorization ?? "";
  const token = header.replace("Bearer ", "");

  // Throws if the token is forged, expired, or from another project.
  const decoded = await getAuth().verifyIdToken(token);

  return decoded.uid; // Now you know who this is, for certain.
}

verifyIdToken checks the signature against Google's public keys, the expiry, and that the token belongs to your project. Only after it returns do you know who is asking.

Custom claims: roles that reach your rules

Custom claims are small pieces of data baked into a user's ID token. They are the standard way to do roles.

// On your server — never from a client.
await getAuth().setCustomUserClaims(uid, { admin: true });

The claim then appears in security rules automatically:

match /invoices/{id} {
  allow read: if request.auth.token.admin == true;
}

Python

There is an official Admin SDK for Python, and it works the same way as the Node one.

import firebase_admin
from firebase_admin import credentials, firestore, auth

cred = credentials.Certificate("service-account.json")
firebase_admin.initialize_app(cred)

db = firestore.client()

# Verify a token from your mobile app
decoded = auth.verify_id_token(id_token)
uid = decoded["uid"]

# Privileged write — no security rules apply here
db.collection("orders").document(order_id).update({"status": "shipped"})

You may also come across Pyrebase. It is a third-party library that wraps the REST API and behaves like a *client*, respecting security rules. It is not the Admin SDK and is not maintained by Google. For server work, use firebase-admin.

Django

There is no Firebase database backend for Django's ORM, and there will not be — Django's ORM expects SQL. What people usually mean by "Django with Firebase" is one of two things:

• Firebase for authentication, Django for everything else. Your frontend signs in with Firebase, sends the ID token to Django, and Django verifies it with the Admin SDK and looks up its own user record. This is a good architecture and quite common.
• Django reading and writing Firestore directly through firebase_admin, alongside or instead of its own database. Workable, but you lose the ORM, migrations and the admin site for that data.

The first is almost always the better idea.

Laravel and PHP

Google does not publish a PHP Admin SDK. The community library kreait/laravel-firebase is the standard answer and is well maintained.

The same architecture applies: Firebase handles sign-in, Laravel verifies the ID token and keeps its own data in MySQL or Postgres. Using Firestore as Laravel's main database means giving up Eloquent, which is usually a bad trade.

Keeping the service account key safe

1. Never commit it. Add the JSON file to .gitignore before you download it, not after.
2. Use environment variables in production. Most hosts let you paste the JSON into a secret. Read it from the environment rather than shipping a file.
3. On Google Cloud, use nothing at all. Cloud Functions, Cloud Run and App Engine provide credentials automatically — call initializeApp() with no arguments and it works.
4. Rotate if exposed. A leaked key is a full database compromise. Revoke it in the Google Cloud console and issue a new one; do not wait to see if anyone noticed.

// Inside Cloud Functions — no key needed, credentials are ambient.
import { initializeApp } from "firebase-admin/app";

initializeApp();