firebase deploy silently ignores Application Default Credentials (ADC) / GOOGLE_APPLICATION_CREDENTIALS in CI — throws "Failed to authenticate, have you run firebase login?" despite valid WIF credentials

[alexjbrandtjr-gif]

firebase-tools:

Platform:

[REQUIRED] Test case

[REQUIRED] Steps to reproduce

[REQUIRED] Expected behavior

[REQUIRED] Actual behavior

Product: firebase-tools
Version affected: v15.x (confirmed v15.17.0; likely all v15 releases)
Environment: GitHub Actions / any CI using google-github-actions/auth with Workload Identity Federation

Problem statement
When firebase deploy is run in a GitHub Actions environment where authentication was established via google-github-actions/auth with Workload Identity Federation, it throws:

Error: Failed to authenticate, have you run firebase login?
This occurs even though:

GOOGLE_APPLICATION_CREDENTIALS is set to a valid credentials file
gcloud auth print-access-token succeeds and returns a valid token
The service account has full roles/firebase.admin and roles/cloudfunctions.developer IAM bindings
Every other GCP API called in the same CI job (Firestore REST API, Storage REST API, gcloud CLI) authenticates successfully with the same credentials
Root cause analysis

The auth resolution chain in requireAuth.js (paraphrased) is:

1. --token CLI flag
2. FIREBASE_TOKEN environment variable
3. configstore (local login via firebase login)
4. autoAuth() via google-auth-library
   Step 4 is where it fails silently. autoAuth() calls google-auth-library's GoogleAuth, which itself reads ADC correctly — but firebase-tools wraps this in a hardcoded timeout. If autoAuth() does not resolve within that window (observed in WIF environments where the credential exchange adds latency), firebase-tools catches the timeout and surfaces the generic "have you run firebase login?" error, discarding the actual ADC failure reason.

Critically, GOOGLE_OAUTH_ACCESS_TOKEN is never consulted anywhere in this chain — not as an env-var shortcut, not as a fallback. This is inconsistent with gcloud, which accepts a raw bearer token via that variable directly.

The result is that the only reliable CI workaround in firebase-tools v15 is the deprecated --token flag with a long-lived OAuth 2.0 refresh token (FIREBASE_TOKEN), which contradicts GCP's current security guidance to use short-lived WIF credentials.

Reproduction steps
Set up a GitHub Actions job using google-github-actions/auth@v3 with workload_identity_provider and service_account (standard WIF setup, create_credentials_file: true, export_environment_variables: true).

In the same job, confirm ADC works:

gcloud auth print-access-token # succeeds, returns valid token
curl -H "Authorization: Bearer $(gcloud auth print-access-token)"
"https://firebase.googleapis.com/v1beta1/projects/my-project" # 200 OK
Attempt a deploy:

pnpm exec firebase deploy --only functions:myFunction --project my-project
Observe:

Error: Failed to authenticate, have you run firebase login?
despite steps 2 confirming valid credentials.

Minimal reproduction config (deploy.yml excerpt):

• uses: google-github-actions/auth@v3
  with:
  workload_identity_provider: ${{ vars.GCP_WORKLOAD_IDENTITY_PROVIDER }}
  service_account: ${{ vars.GCP_DEPLOY_SERVICE_ACCOUNT }}
  create_credentials_file: true
  export_environment_variables: true # sets GOOGLE_APPLICATION_CREDENTIALS
• run: |
  gcloud auth print-access-token # ✅ works
  pnpm exec firebase deploy --only functions # ❌ "Failed to authenticate"

Expected behavior
firebase deploy should respect GOOGLE_APPLICATION_CREDENTIALS / ADC as a valid authentication path, consistent with every other Google Cloud SDK and client library. Minimally, one of:

Option A: Honor a GOOGLE_OAUTH_ACCESS_TOKEN environment variable as a direct bearer-token override (identical to gcloud's behavior).

Option B: Remove or significantly increase the timeout on autoAuth() so ADC via WIF credential exchange is given sufficient time to complete.

Option C: Surface the actual ADC error in the thrown exception rather than discarding it and replacing it with the generic "have you run firebase login?" message — this would at minimum allow users to diagnose the real problem.

Workaround
Bypass firebase-tools for Cloud Functions deployment by calling the Cloud Functions v2 REST API directly, using a bearer token from gcloud auth print-access-token:

// generateUploadUrl → upload zip → PATCH each function → poll operations
const token = execSync('gcloud auth print-access-token', { encoding: 'utf8' }).trim();
// Upload source
const { uploadUrl, storageSource } = await fetch(
https://cloudfunctions.googleapis.com/v2/projects/${project}/locations/${region}/functions:generateUploadUrl,
{ method: 'POST', headers: { Authorization: Bearer ${token}, 'Content-Type': 'application/json' }, body: '{}' }
).then(r => r.json());
// PATCH each function to reference the new source
const op = await fetch(
https://cloudfunctions.googleapis.com/v2/projects/${project}/locations/${region}/functions/${name}?updateMask=buildConfig.source,
{ method: 'PATCH', headers: { Authorization: Bearer ${token}, 'Content-Type': 'application/json' },
body: JSON.stringify({ buildConfig: { source: { storageSource } } }) }
).then(r => r.json());
This API accepts any valid GCP bearer token. The google-github-actions/auth WIF credentials work perfectly via this path — only firebase-tools' own auth layer rejects them.

Additional context: This regression likely affects any user who followed GCP's guidance to migrate from long-lived service account keys to Workload Identity Federation in GitHub Actions CI. The symptom (a generic "have you run firebase login?" error with no indication ADC was attempted) makes it appear to be a login issue rather than a timeout/auth-chain-ordering bug, which significantly increases debugging time.

[alexjbrandtjr-gif]

And if you are like me with V1 functions because an equivalent doesn't exist in V2 Functions, here is a fall back workaround for V1 functions to deploy

1. The lazy v1 upload getter

Called at most once per deploy run, no matter how many Gen 1 functions exist:

function makeV1UploadUrlGetter(project, region, token, zipPath) {
let promise = null;
return () => {
if (!promise) {
promise = (async () => {
// Ask GCP for a v1-specific signed GCS URL
const url = ${V1_CF_API}/projects/${project}/locations/${region}/functions:generateUploadUrl;
const result = await call('POST', url, token, {});
// Upload the same zip that was already uploaded to v2
await uploadZip(result.uploadUrl, zipPath);
return result.uploadUrl;
})();
}
return promise; // subsequent callers get the same Promise — one upload total
};
}

2. The PATCH with fallback

Tries v2 first. On HTTP 404, switches to the v1 body shape

async function patchFunction(fnName, project, region, token, storageSource, getV1UploadUrl) {
// ── Attempt v2 ──────────────────────────────────────────────────────────────
const v2Url = ${CF_API}/projects/${project}/locations/${region}/functions/${fnName}
+ ?updateMask=buildConfig.source;
const v2Body = { buildConfig: { source: { storageSource } } };

let op;
try {
op = await call('PATCH', v2Url, token, v2Body);
} catch (err) {
// ── v2 404 → Gen 1 function, fall back to v1 API ────────────────────────
if (!err.message.includes('HTTP 404')) throw err;

const v1UploadUrl = await getV1UploadUrl(); // lazy — uploads zip once

const v1PatchUrl = `${V1_CF_API}/projects/${project}/locations/${region}/functions/${fnName}`
                 + `?updateMask=sourceUploadUrl`;
const v1Body = {
  name: `projects/${project}/locations/${region}/functions/${fnName}`,
  sourceUploadUrl: v1UploadUrl,   // ← v1 uses URL, not bucket/object
};

op = await call('PATCH', v1PatchUrl, token, v1Body);
return { opName: op.name, fnName };

}

return { opName: op.name, fnName };
}

3. Polling — routing to the right API

v2 operation names start with projects/; v1 names start with operations/:

const apiBase = opName.startsWith('operations/') ? V1_CF_API : CF_API;
op = await call('GET', ${apiBase}/${opName}, token);

[splincode]

I had the same issue
https://github.com/taiga-family/taiga-ui/actions/runs/28218751217/job/83595202731?pr=14440

[elephantum]

@splincode today we started to have the same issue with "supplied version projects/... is the current active version." what we also notice, that the deploy actually completes correctly, just the error report is misguiding

[shojiiii]

I ran into the same symptom (Failed to authenticate, have you run firebase login? in GitHub Actions with Workload Identity Federation), but in our case --debug revealed the real error that was being swallowed. The cause was neither a timeout nor the credentials — it was a bug in Node.js itself.

The actual error from firebase deploy --debug:

Error: Invalid response body while trying to fetch https://sts.googleapis.com/v1/token: Premature close
    at StsCredentials.exchangeToken (.../google-auth-library/.../stscredentials.js)
    at IdentityPoolClient...getAccessToken
    at autoAuth (firebase-tools/lib/requireAuth.js)

gcloud auth print-access-token succeeded and GOOGLE_APPLICATION_CREDENTIALS was set correctly, yet only the STS token exchange inside firebase-tools failed with Premature close.

The root cause is a Node.js regression:

• The 2026-06 security fix (CVE-2026-48931 / http: fix response queue poisoning in http.Agent) broke keep-alive socket reuse, causing ERR_STREAM_PREMATURE_CLOSE on consecutive requests to googleapis.
• Broken in: Node 24.17.0 / 22.23.0, fixed in: 24.18.0 / 22.23.1 (fix: http: avoid stream listeners on idle agent sockets nodejs/node#64004)
• Upstream issue: http: node-fetch throws ERR_STREAM_PREMATURE_CLOSE on keep-alive socket closures after latest security releases nodejs/node#63989

Pinning our CI Node to 24.18.0 fixed it completely.

Because the original error was masked, it took a while to realize the cause was on the Node side. Having the actual error message surfaced would have made diagnosis much easier, so Option C (surfacing the real ADC/STS error instead of discarding it) would be very helpful.

[splincode]

@shojiiii Pinning our CI Node to 24.18.0 fixed it completely.

Thank you very much!

[jamesadhitthana]

@shojiiii thanks it works! 24.17.0 is broken for all our systems, once updated to 24.18.0 it just works!

[aalej]

Apologies for the issue here folks. As @shojiiii mentioned, this seems like an issue related to the Node.js 24.17.0 bug nodejs/node#63989. Node.js 24.18.0 should resolve the issue. firebase-tools 15.22.3 also has a fix for this in #10717.

To resolve this issue, please use either Node.js 24.18.0, or upgrade firebase-tools to 15.22.3. A detailed explanation of why this issue occurred in fireabse-tools can be found here #10716 (comment)

[alexjbrandtjr-gif]

I ran into the same symptom (Failed to authenticate, have you run firebase login? in GitHub Actions with Workload Identity Federation), but in our case --debug revealed the real error that was being swallowed. The cause was neither a timeout nor the credentials — it was a bug in Node.js itself.

The actual error from firebase deploy --debug:

Error: Invalid response body while trying to fetch https://sts.googleapis.com/v1/token: Premature close
    at StsCredentials.exchangeToken (.../google-auth-library/.../stscredentials.js)
    at IdentityPoolClient...getAccessToken
    at autoAuth (firebase-tools/lib/requireAuth.js)

gcloud auth print-access-token succeeded and GOOGLE_APPLICATION_CREDENTIALS was set correctly, yet only the STS token exchange inside firebase-tools failed with Premature close.

The root cause is a Node.js regression:

• The 2026-06 security fix (CVE-2026-48931 / http: fix response queue poisoning in http.Agent) broke keep-alive socket reuse, causing ERR_STREAM_PREMATURE_CLOSE on consecutive requests to googleapis.
• Broken in: Node 24.17.0 / 22.23.0, fixed in: 24.18.0 / 22.23.1 (fix: http: avoid stream listeners on idle agent sockets nodejs/node#64004)
• Upstream issue: http: node-fetch throws ERR_STREAM_PREMATURE_CLOSE on keep-alive socket closures after latest security releases nodejs/node#63989

Pinning our CI Node to 24.18.0 fixed it completely.

Because the original error was masked, it took a while to realize the cause was on the Node side. Having the actual error message surfaced would have made diagnosis much easier, so Option C (surfacing the real ADC/STS error instead of discarding it) would be very helpful.

Thank you!! This fixed my problem. Workaround removed