Providers / Firebase

Cloud

Firebase API keys and credentials

What every Firebase credential a founder holds does, whether it expires, and what tends to break. Each fact links to Firebase's own docs.

Last checked 2026-11-06 · firebase.google.com

At a glance

Each credential

Admin SDK service account private key (JSON)

• Doesn't expire
• Can be scoped

Generate in Firebase console: Settings > Service accounts > Generate New Private Key. The Firebase page does not state expiry. Underlying Google Cloud docs say service account keys never expire by default, but an org policy can set a maximum validity. Each service account can have up to 10 keys. Deletion is permanent and cannot be undone, so disable the key first and confirm nothing breaks. Google Cloud recommends rotating at least every 90 days (create new key, switch apps, disable old, delete old). Permissions come from IAM roles on the service account. Org policy iam.disableServiceAccountKeyCreation blocks key creation and is enforced by default on organizations created on or after May 3, 2024.

Firebase docs

Web API key (Firebase config)

• Not documented
• Can be scoped

Firebase docs say these keys identify the project and app and are OK to include in code; access control comes from Security Rules and App Check. Keys Firebase creates are automatically restricted to an allowlist of Firebase APIs. Deleting a key is permanent. Docs do not state an expiry. Keys for other Google APIs (such as Gemini) must be protected and are not Firebase keys.

Firebase docs

FCM HTTP v1 access token (minted from service account)

• Not documented
• Can be scoped

Short-lived OAuth 2.0 access token minted from the service account, with scope https://www.googleapis.com/auth/firebase.messaging. Sent as Authorization: Bearer. The Admin SDK handles this automatically. Token lifetime was not confirmed from the docs reviewed. Not stored long term; the key that mints it is the credential to protect.

Firebase docs

Firebase console login (Google account)

• Not documented

Sign-in uses a Google account. Not an API credential. Session policy not researched.

What usually goes wrong

• Admin SDK private key committed to a repo or uploaded in a client bundle; keys do not expire, so the leak stays valid until deleted
• Old service account key deleted before every deployment switched to the new one, causing outages (deletion cannot be undone)
• Organization policy blocks new key creation, so an automation that generates keys fails

Renewals and billing

• Firebase billing plan (Spark or Blaze). Plan type and billing cadence not researched. Blaze is billed through the linked Google Cloud billing account.

Not researched.

What Firebase's docs don't say

We couldn't confirm these from official docs, so don't rely on them either way:

• Whether Firebase service account keys can be checked for expiry via API (Google Cloud key list fields not confirmed)
• Default and maximum org-policy key validity values (iam.serviceAccountKeyExpiryHours not researched)
• FCM HTTP v1 access token lifetime (typically short-lived, not confirmed)
• Legacy FCM server key status and shutdown date (the migration page returned 404 and the auth page did not mention it)
• APNs auth key (.p8) used by FCM for iOS (not researched)
• Firebase Web API key rotation procedure
• Billing model, usage API, and plan cadence

Rotating or replacing a Firebase key

The steps are the same for most providers: make the new key, deploy it everywhere the old one is used, check it works, then revoke the old one. Our guides walk through it:

Sources

• firebase.google.com/docs/admin/setup
• firebase.google.com/docs/projects/api-keys
• firebase.google.com/docs/cloud-messaging/auth-server
• docs.cloud.google.com/iam/docs/keys-create-delete

Related providers

Keep track of every Firebase key

StackHangar stores your Firebase keys in an encrypted vault, grouped by the product they belong to, warns you before they expire, and walks you through rotating them. We can't read your secrets.