Firebase Auth Security: IAM Policies and Network Security

Understanding IAM Policies in Firebase Auth Security

Identity and Access Management (IAM) policies in Google Cloud govern who can perform what actions on your Firebase project and its resources. When it comes to Firebase Authentication, IAM policies control administrative operations like managing user accounts, viewing authentication logs, modifying OAuth configurations, and integrating with third-party identity providers. Without properly configured IAM policies, a project is exposed to risks ranging from accidental user data exposure to deliberate abuse by overly permissive service accounts.

How IAM Works with Firebase Auth

Firebase Auth sits on top of Google Cloud's identity platform. Every Firebase project is backed by a Google Cloud project, which means all IAM roles and permissions apply directly. The key Firebase Auth–related permissions are grouped under roles like Firebase Authentication Admin, Firebase Authentication Viewer, and Firebase Admin. These roles allow specific actions:

Firebase Authentication Admin (roles/firebaseauth.admin) – Full control over authentication settings, user management, and provider configurations.
Firebase Authentication Viewer (roles/firebaseauth.viewer) – Read-only access to user lists, audit logs, and configurations.
Firebase Admin (roles/firebase.admin) – Broad project-level access that includes Auth management plus other Firebase services.
Service Account Token Creator (roles/iam.serviceAccountTokenCreator) – Allows generation of custom tokens, often needed for backend services.

Additionally, custom IAM policies can be built using conditions and granular permissions to enforce attribute-based access control (ABAC) or time-bound access.

Why IAM Policies Matter

Consider a typical development team: frontend engineers, backend developers, QA testers, and DevOps personnel. Not everyone needs full administrative access to Firebase Auth. By applying the principle of least privilege with IAM, you:

Prevent accidental deletion of production user accounts.
Restrict sensitive OAuth client secrets to only those who require them.
Ensure audit logs cannot be tampered with by unauthorized users.
Limit blast radius when credentials are compromised.

IAM policies also integrate with Google Cloud's audit logging (Cloud Audit Logs), giving you full traceability of who changed what and when in Firebase Auth settings.

Network Security for Firebase Auth

🚀 Deploy your AI agent in 10 minutes

Managed Hermes hosting. Zero DevOps. 100M tokens/mo included.

Try it free →

While IAM controls who can access resources, network security controls where and how requests can originate. For Firebase Auth, network security typically involves two complementary layers:

Google Cloud VPC Service Controls – Restricting which networks can reach Firebase/Google Cloud APIs, including the Auth management APIs.
Firebase App Check – Ensuring that requests to your Firebase backend (including Auth triggers) come only from genuine, attested client applications.

VPC Service Controls and Perimeters

VPC Service Controls create a security perimeter around your Google Cloud resources. When enabled for Firebase services (like the Identity Platform API used by Firebase Auth), all administrative API calls must originate from within allowed networks (RFC1918, authorized IP ranges, or trusted VPCs). This effectively prevents an attacker with stolen IAM credentials from making changes to Auth configurations from outside your corporate network.

A typical configuration looks like this:

# Define a service perimeter that includes Firebase Auth APIs
gcloud access-context-manager perimeters create AuthSecurePerimeter \
  --title="Firebase Auth Admin Restriction" \
  --policy=YOUR_ACCESS_POLICY_ID \
  --resources=projects/YOUR_PROJECT_NUMBER \
  --restricted-services=identitytoolkit.googleapis.com,firebase.googleapis.com \
  --allowed-vpc-networks=projects/YOUR_PROJECT_ID/global/networks/prod-vpc

After this perimeter is applied, any call to the Firebase Auth admin API (e.g., to delete a user or change an OAuth provider) will be blocked unless it comes from the specified VPC network or an allowed IP range. Developers working from home must connect via a VPN or Identity-Aware Proxy to reach the admin endpoints.

Firebase App Check as Application-Level Network Security

App Check is Firebase's built-in attestation service. It verifies that incoming requests to your Firebase backend originate from your genuine app running on a legitimate, untampered device. While this doesn't directly protect the Auth management APIs (those are IAM-protected), it secures the client-side authentication flow and any Cloud Functions triggered by Auth events.

For example, if you have a Cloud Function that creates a user document in Firestore upon new Auth registrations, enforcing App Check on that function ensures only requests that possess a valid App Check token can invoke it. This prevents malicious actors from flooding your function with fake sign-up events.

Practical Implementation: IAM Policies

Let's walk through a real-world setup. Assume you have a project with a dedicated CI/CD service account, a team of developers, and a security auditor.

Step 1: Grant the Minimal Required Roles

Use the gcloud CLI to assign roles precisely.

# Grant a developer read-only access to Auth for debugging
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="user:developer@example.com" \
  --role="roles/firebaseauth.viewer" \
  --condition="expression=request.time < timestamp('2026-01-01T00:00:00Z'),title=Temporary access"

# Grant the CI/CD service account admin access for automated deployments
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="serviceAccount:ci-cd@YOUR_PROJECT_ID.iam.gserviceaccount.com" \
  --role="roles/firebaseauth.admin"

# Grant the security auditor read access to all auth logs
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="user:auditor@example.com" \
  --role="roles/logging.viewer" \
  --condition="expression=resource.type == 'identity_toolkit.googleapis.com/UserEvent',title=Only Auth logs"

The conditions above demonstrate attribute-based access control. The developer gets temporary read-only access, and the auditor's view is scoped to Auth-related logs only.

Step 2: Protect Sensitive Actions with Custom IAM Conditions

You can further restrict dangerous operations using IAM conditional role bindings. For example, only allow deleting a user if the request comes from a specific allowed IP range (even for admins):

# Admin can delete users only from the office IP range
gcloud projects add-iam-policy-binding YOUR_PROJECT_ID \
  --member="user:admin@example.com" \
  --role="roles/firebaseauth.admin" \
  --condition="expression=request.ip in ['203.0.113.0/24'] || request.ip in ['198.51.100.0/24'],title=DeleteUserFromOfficeOnly,description=Restrict user deletion to office IPs"

Note: IAM conditions are evaluated at the policy enforcement point, and the request.ip attribute refers to the source IP of the API call. This adds a network-level dimension to your IAM policy.

Practical Implementation: Network Security

Combine VPC Service Controls and App Check to build layered defenses.

Step 1: Create a VPC Service Perimeter for Auth APIs

First, ensure you have an Access Context Manager policy (organization-level). Then create the perimeter:

# Create the perimeter with dry-run mode first to test impact
gcloud access-context-manager perimeters create AuthAdminPerimeter \
  --title="Firebase Auth Admin Perimeter" \
  --policy=ACCESS_POLICY_ID \
  --resources=projects/YOUR_PROJECT_NUMBER \
  --restricted-services=identitytoolkit.googleapis.com,firebase.googleapis.com \
  --dry-run

After verifying no legitimate traffic is blocked, finalize the perimeter:

gcloud access-context-manager perimeters update AuthAdminPerimeter \
  --policy=ACCESS_POLICY_ID \
  --no-dry-run \
  --add-allowed-vpc-networks=projects/YOUR_PROJECT_ID/global/networks/prod-management-vpc \
  --add-allowed-access-levels=YOUR_ACCESS_LEVEL_FOR_VPN_USERS

Now any attempt to use the firebase auth:delete command or the Admin SDK outside the allowed network will receive a “VPC Service Controls” denial error. This is a powerful guardrail against credential theft.

Step 2: Enforce App Check on Auth-Triggered Cloud Functions

When a new user registers, a common pattern is to trigger a Cloud Function that creates a Firestore profile. Protect that function with App Check.

First, install App Check in your client app and obtain a token. Then, in your Cloud Function (using Firebase Admin SDK), verify the token:

const admin = require('firebase-admin');
admin.initializeApp();

// Auth trigger: onCreate user
exports.createUserProfile = functions.auth.user().onCreate(async (user) => {
  // App Check token is passed in context for callable functions,
  // but for Auth triggers we rely on the request having been validated
  // by the Firebase platform. For HTTP callable functions, use:
  // const appCheckClaims = context.app; // if using callable functions
  // However, for Auth triggers, Firebase guarantees the event is genuine
  // from Firebase Auth itself. To protect downstream Firestore writes,
  // enforce App Check in Firestore security rules instead.
});

For HTTP callable functions that are invoked directly by clients, use:

exports.verifyPhoneNumber = functions.https.onCall(async (data, context) => {
  // Ensure App Check token is valid
  if (!context.app || context.app.undefined) {
    throw new functions.https.HttpsError('failed-precondition',
      'The function must be called from a verified app.');
  }
  // Proceed with sensitive logic...
});

In Firestore security rules, you can also require App Check:

rules_version = '2';
service cloud.firestore {
  match /databases/{database}/documents {
    match /users/{userId} {
      allow write: if request.auth.uid != null &&
                     request.auth.token.firebase.sign_in_provider != 'anonymous' &&
                     request.headers['x-firebase-appcheck'] == 'valid';
    }
  }
}

This ensures that even if an attacker manages to obtain a valid auth token (e.g., via phishing), they still need to present a valid App Check token, which is tied to the genuine app.

Best Practices

Apply least privilege relentlessly. Grant firebaseauth.admin only to automated service accounts, and give humans firebaseauth.viewer with temporary conditions when needed.
Use IAM Conditions for sensitive operations. Require MFA, specific IP ranges, or time-bound access for user deletion or OAuth secret modifications.
Wrap administrative APIs in a VPC Service Control perimeter. Even if a developer accidentally pushes a credential, the API call from an external coffee shop will fail.
Enable App Check for all client-facing endpoints. Combine with strong Firestore Security Rules and Cloud Function enforcement to prevent abuse of Auth-triggered logic.
Monitor with Cloud Audit Logs. Stream Auth admin activity logs to your SIEM and set alerts for anomalies like mass user deletion or unexpected provider changes.
Rotate service account keys regularly. Treat the CI/CD service account that holds firebaseauth.admin as high-value and use workload identity federation instead of static keys where possible.

Conclusion

Firebase Auth security extends far beyond strong password policies and multi-factor authentication for end users. By leveraging Google Cloud IAM policies, you tightly control who can touch your authentication infrastructure. Adding network security with VPC Service Controls and App Check creates defense in depth—ensuring that even valid credentials are useless from untrusted networks or tampered clients. Implement these layers together, and you transform your Firebase project from a single point of failure into a hardened identity fortress, fully auditable and resilient against both insider mistakes and external threats.