Why OTP Authentication Matters

One‑time passwords (OTP) have become a cornerstone of modern security architectures. By delivering a short‑lived numeric code to a user’s phone, OTP adds a dynamic factor that drastically reduces the risk of credential theft. When combined with Firebase’s Phone Auth service, developers obtain a scalable, low‑maintenance solution that works across Android, iOS, and the web.

Target Audience

This guide is intended for backend engineers who need to integrate Firebase OTP authentication into an existing server‑side stack (Node.js/Express, Python, or Java) while retaining full control over verification, rate limiting, and custom token generation. Readers should be comfortable with REST APIs, asynchronous programming, and basic security concepts.

What You Will Build

By the end of the tutorial you will have a production‑ready flow that:

1. Initiates an OTP request from the client.
2. Verifies the OTP securely on the server.
3. Generates a custom Firebase token for subsequent authenticated calls.
4. Handles edge cases such as re‑sending limits, fraud detection, and multi‑factor expansion.

The implementation follows defense‑in‑depth principles and stays compatible with Firebase’s recommended security model.

High‑Level Data Flow

mermaid sequenceDiagram participant C as Client (Web / Mobile) participant FB as Firebase Auth Service participant S as Backend (Node.js/Express) C->>FB: request OTP (phoneNumber) FB-->>C: SMS with verificationCode C->>S: POST /auth/verify { verificationId, code } S->>FB: verifyPhoneNumber(verificationId, code) FB-->>S: verificationSuccess S->>FB: createCustomToken(uid) FB-->>S: customToken S-->>C: { customToken } C->>FB: signInWithCustomToken(customToken) FB-->>C: userCredential

Core Components

Component	Responsibility
Client SDK	Initiates OTP request using firebase.auth().signInWithPhoneNumber and collects the verification code from the user.
Firebase Auth Service	Sends SMS, validates the verification code, and creates custom tokens when requested by a trusted backend.
Backend Server	Acts as a trusted verifier, applies additional security layers (rate limiting, IP checks, audit logging), and issues custom tokens for the client.

Why a Backend Verification Layer?

Firebase automatically verifies OTP on the client, but exposing that flow directly can lead to abuse:

• Replay attacks if the verification ID is intercepted.
• Unlimited OTP requests from malicious scripts.
• Lack of audit trails for compliance.

By inserting a server‑side verification step, you retain full observability and can enforce policies such as per‑IP throttling, device fingerprinting, and integration with fraud‑detection services.

Security Zones

1. Public Zone - Client code, accessible to anyone.
2. Trusted Zone - Backend server, protected by firewalls and mutual TLS.
3. Secure Cloud Zone - Firebase Auth, managed by Google with FIPS‑compliant encryption.

All communication between the client and backend must happen over HTTPS, and the backend must authenticate itself to Firebase using a service account.

Data Model

{ "uid": "string", // Firebase UID "phoneNumber": "+1234567890", "lastOtpSentAt": "ISO8601", "otpRequestCount": 3, "blocked": false }

The model is stored in Firestore or any relational DB of your choice, enabling quick look‑ups for rate‑limit checks and audit logs.

Prerequisites

• A Firebase project with Phone Authentication enabled.
• Service account JSON downloaded from the Firebase console.
• Node.js ≥ 14 with Express installed.
• Optional: Firestore database for persisting OTP metadata.

1. Set Up the Firebase Admin SDK

// server/firebaseAdmin.js
const admin = require('firebase-admin');
const serviceAccount = require('./serviceAccountKey.json');

admin.initializeApp({ credential: admin.credential.cert(serviceAccount), databaseURL: 'https://<PROJECT_ID>.firebaseio.com' });

module.exports = admin;

2. Configure the Express Routes

// server/routes/auth.js
const express = require('express');
const router = express.Router();
const admin = require('../firebaseAdmin');
const { body, validationResult } = require('express-validator');
const rateLimiter = require('../middleware/rateLimiter');

// Verify OTP endpoint router.post( '/verify', rateLimiter, body('verificationId').isString(), body('code').isLength({ min: 6, max: 6 }), async (req, res) => { const errors = validationResult(req); if (!errors.isEmpty()) { return res.status(400).json({ errors: errors.array() }); }

const { verificationId, code, phoneNumber } = req.body;
try {
  // 1️⃣ Verify the OTP with Firebase
  const credential = admin.auth.PhoneAuthProvider.credential(
    verificationId,
    code
  );
  const userRecord = await admin.auth().signInWithCredential(credential);

  // 2️⃣ Create a custom token for the client
  const customToken = await admin.auth().createCustomToken(userRecord.uid);

  // 3️⃣ Persist audit data (optional)
  // await db.collection('otpLogs').add({ phoneNumber, verifiedAt: new Date() });

  res.json({ customToken });
} catch (err) {
  console.error('OTP verification failed:', err);
  res.status(401).json({ message: 'Invalid verification code.' });
}

} );

module.exports = router;

3. Rate‑Limiting Middleware (Advanced)

// server/middleware/rateLimiter.js
const LRU = require('lru-cache');
const cache = new LRU({ max: 5000, ttl: 60 * 1000 }); // 1‑minute window

module.exports = (req, res, next) => { const ip = req.ip; const count = (cache.get(ip) || 0) + 1; cache.set(ip, count); if (count > 5) { return res.status(429).json({ message: 'Too many requests. Try later.' }); } next(); };

The middleware limits each IP to 5 verification attempts per minute, mitigating brute‑force attacks.

4. Client‑Side Flow (Web Example)

<!DOCTYPE html>
<html>
<head>
  <script src="https://www.gstatic.com/firebasejs/9.22.0/firebase-app-compat.js"></script>
  <script src="https://www.gstatic.com/firebasejs/9.22.0/firebase-auth-compat.js"></script>
</head>
<body>
  <input id="phone" placeholder="+1234567890" />
  <button id="sendOtp">Send OTP</button>
  <br/>
  <input id="code" placeholder="6‑digit code" />
  <button id="verifyOtp">Verify OTP</button>

<script> const firebaseConfig = {/* your config */}; firebase.initializeApp(firebaseConfig); const auth = firebase.auth(); let verificationId = null; document.getElementById('sendOtp').addEventListener('click', async () => { const phone = document.getElementById('phone').value; const recaptchaVerifier = new firebase.auth.RecaptchaVerifier('sendOtp', { size: 'invisible' }); const confirmation = await auth.signInWithPhoneNumber(phone, recaptchaVerifier); verificationId = confirmation.verificationId; alert('OTP sent!'); }); document.getElementById('verifyOtp').addEventListener('click', async () => { const code = document.getElementById('code').value; const response = await fetch('/auth/verify', { method: 'POST', headers: { 'Content-Type': 'application/json' }, body: JSON.stringify({ verificationId, code, phoneNumber: document.getElementById('phone').value }) }); const data = await response.json(); if (response.ok) { await auth.signInWithCustomToken(data.customToken); alert('Authenticated!'); } else { alert(data.message || 'Verification failed'); } }); </script> </body> </html>

Key points:

• The client only receives a verificationId (not the OTP) which is sent to the server for validation.
• The server returns a custom token that the client then uses to sign in via signInWithCustomToken.

5. Handling Edge Cases

a) Re‑Sending OTP

Implement a separate endpoint that checks the lastOtpSentAt timestamp. Enforce a minimum interval (e.g., 30 seconds) before allowing another OTP request.

b) Expired Verification IDs

Firebase verification IDs expire after ~10 minutes. Return a clear error (429 Too Many Requests) prompting the client to start a fresh OTP flow.

c) International Phone Numbers

Validate phone numbers using the libphonenumber-js library before forwarding them to Firebase to avoid malformed inputs.

const { parsePhoneNumberFromString } = require('libphonenumber-js');
function isValidPhone(number) {
  const phone = parsePhoneNumberFromString(number);
  return phone && phone.isValid();
}

6. Extending to Multi‑Factor Authentication (MFA)

Once the user is signed in with the custom token, you can enroll additional factors (e.g., TOTP apps) using Firebase’s Multi‑Factor API. The flow remains identical; you simply call user.multiFactor.enroll on the client after the initial OTP login.

// After signInWithCustomToken
const user = firebase.auth().currentUser;
const totpFactor = firebase.auth.PhoneMultiFactorGenerator.assertion(
  firebase.auth.PhoneAuthProvider.credential(verificationId, code)
);
await user.multiFactor.enroll(totpFactor, 'My Authenticator App');

This grants a layered security posture that satisfies compliance frameworks such as PCI‑DSS and GDPR.

Frequently Asked Questions

1️⃣ Can I bypass the backend verification and use Firebase’s client‑only OTP flow?

Yes, Firebase supports a direct client‑side flow, but doing so removes critical controls such as rate limiting, audit logging, and custom claim assignment. For production systems handling sensitive data, a server‑side verification layer is strongly recommended.

2️⃣ How do I protect the service‑account credentials from leaking?

Store the JSON key in a secret manager (e.g., Google Secret Manager, AWS Secrets Manager) and inject it into the runtime via environment variables. Never commit the file to version control, and restrict IAM permissions to the minimum required role (roles/firebase.admin).

3️⃣ What happens if the user changes their phone number after OTP verification?

Treat the phone number as a mutable claim. After successful verification, update the user’s profile with admin.auth().updateUser(uid, { phoneNumber }). If the number changes, you may need to re‑verify to prevent account takeover.

4️⃣ Is there a limit on how many OTPs I can send per day?

Firebase imposes a quota of 10 SMS per phone number per hour and 100 SMS per project per day for the free tier. Monitor usage via the Firebase console and request quota increases if needed.

5️⃣ How can I integrate fraud detection?

Combine the OTP endpoint with a third‑party risk engine (e.g., Sift, Google reCAPTCHA Enterprise). Pass the client’s IP, device fingerprint, and request metadata to the engine before invoking Firebase verification. Reject any request flagged as high risk.

These answers cover the most common operational concerns when deploying Firebase OTP authentication at scale.

Bringing It All Together

Implementing OTP authentication with Firebase, while seemingly straightforward, becomes truly enterprise‑ready only after you layer a robust backend verification step, enforce rate limiting, and adopt best‑practice security controls. The architecture outlined above gives you a clear separation of concerns:

1. Client - Handles UI and initiates OTP requests.
2. Backend - Validates OTPs, applies policies, and issues custom tokens.
3. Firebase Auth - Guarantees delivery of SMS, cryptographic verification, and token generation.

By following the code samples, architecture guidelines, and FAQ insights, you’ll be equipped to deliver a secure, scalable, and maintainable authentication experience that meets modern compliance standards. Keep monitoring Firebase’s quota limits, rotate service‑account keys regularly, and stay abreast of emerging threats to ensure your OTP system remains resilient for years to come.