Environment
google-auth-library: 11.0.2 (also reproduced on 10.6.2)
- Node.js: 20.19.5
- Credential type:
external_account (Workload Identity Federation, file-sourced OIDC subject token)
Summary
getErrorFromOAuthErrorResponse() — core/packages/google-auth-library-nodejs/src/auth/oauth2common.ts:253 — builds a new Error from an OAuth/STS error response and copies the original error's own properties onto it — including stack — as non-writable:
const keys = Object.keys(err);
if (err.stack) {
// Copy error.stack if available.
keys.push('stack');
}
keys.forEach(key => {
if (key !== 'message') {
Object.defineProperty(newError, key, {
value: err[key],
writable: false, // <-- makes `stack` read-only
enumerable: true,
});
}
});
Every error surfaced from an STS/OAuth error response therefore has stack with { writable: false, enumerable: true, configurable: true }, whereas a normal Error has a writable stack.
Why it matters
Appending to error.stack to attach causal context is a common pattern, and it is normally safe. Against these errors it throws in strict mode (and silently discards the write in sloppy mode). Both outcomes are bad, and the strict-mode one is worse: the real authentication failure is replaced by a TypeError naming an unrelated library.
A concrete case in the same ecosystem — @google-cloud/firestore's wrapError() (build/src/util.js) does:
err.stack += '\nCaused by: ' + stack;
Its module is emitted with "use strict", and it is invoked from stream 'error' handlers. So when a Firestore operation fails because a federated credential was rejected, the TypeError is thrown inside an EventEmitter emit, escapes the promise chain, and becomes an uncaughtException rather than a rejected promise:
TypeError: Cannot assign to read only property 'stack' of object 'Error: Error code invalid_grant: ID Token issued at <ts> is stale to sign-in.'
at wrapError (/app/node_modules/@google-cloud/firestore/build/src/util.js:213:15)
at Transform.emit (node:events:524:28)
at emitErrorNT (node:internal/streams/destroy:169:8)
at process.processTicksAndRejections (node:internal/process/task_queues:82:21)
The underlying problem was an expired OIDC subject token. Nothing in what the process reported says so. I've filed the counterpart issue for the Firestore half (same monorepo) asking them to guard the assignment: #9154. But the read-only stack looks worth revisiting here too, since any consumer decorating errors this way will hit it, and stack is conventionally writable.
Also note enumerable: true on the copied properties: stack is normally non-enumerable, so this additionally makes it show up in Object.keys(err), for...in, and JSON.stringify output of the error's own properties.
Reproduction
// npm i google-auth-library
const { getErrorFromOAuthErrorResponse } = require('google-auth-library/build/src/auth/oauth2common.js');
const authError = getErrorFromOAuthErrorResponse(
{ error: 'invalid_grant', error_description: 'ID Token is stale to sign-in.' },
new Error('underlying transport failure'),
);
console.log(Object.getOwnPropertyDescriptor(authError, 'stack'));
// => { value: '...', writable: false, enumerable: true, configurable: true }
// Sloppy mode: the write is silently discarded.
(function () { authError.stack += '\nCaused by: x'; })();
// Strict mode (what compiled TS/ESM consumers run in): throws.
(function () { 'use strict'; authError.stack += '\nCaused by: x'; })();
// => TypeError: Cannot assign to read only property 'stack' of object
// 'Error: Error code invalid_grant: ID Token is stale to sign-in.'
In situ this is reached via a normal external_account credential whose subject token has expired: the STS response is an invalid_grant, getErrorFromOAuthErrorResponse() converts it, and any downstream err.stack += then crashes.
Suggested fix
Leave stack writable (and non-enumerable) when copying, so these errors behave like ordinary ones:
keys.forEach(key => {
if (key !== 'message') {
Object.defineProperty(newError, key, {
value: err[key],
writable: key === 'stack',
enumerable: key !== 'stack',
configurable: true,
});
}
});
Simply not copying stack at all would also work — newError already has its own accurate stack — though that loses the original call site. Alternatively newError.cause = err conveys the same information using the standard mechanism and keeps stack untouched.
Environment
google-auth-library: 11.0.2 (also reproduced on 10.6.2)external_account(Workload Identity Federation, file-sourced OIDC subject token)Summary
getErrorFromOAuthErrorResponse()—core/packages/google-auth-library-nodejs/src/auth/oauth2common.ts:253— builds a newErrorfrom an OAuth/STS error response and copies the original error's own properties onto it — includingstack— as non-writable:Every error surfaced from an STS/OAuth error response therefore has
stackwith{ writable: false, enumerable: true, configurable: true }, whereas a normalErrorhas a writablestack.Why it matters
Appending to
error.stackto attach causal context is a common pattern, and it is normally safe. Against these errors it throws in strict mode (and silently discards the write in sloppy mode). Both outcomes are bad, and the strict-mode one is worse: the real authentication failure is replaced by aTypeErrornaming an unrelated library.A concrete case in the same ecosystem —
@google-cloud/firestore'swrapError()(build/src/util.js) does:Its module is emitted with
"use strict", and it is invoked from stream'error'handlers. So when a Firestore operation fails because a federated credential was rejected, theTypeErroris thrown inside anEventEmitteremit, escapes the promise chain, and becomes anuncaughtExceptionrather than a rejected promise:The underlying problem was an expired OIDC subject token. Nothing in what the process reported says so. I've filed the counterpart issue for the Firestore half (same monorepo) asking them to guard the assignment: #9154. But the read-only
stacklooks worth revisiting here too, since any consumer decorating errors this way will hit it, andstackis conventionally writable.Also note
enumerable: trueon the copied properties:stackis normally non-enumerable, so this additionally makes it show up inObject.keys(err),for...in, andJSON.stringifyoutput of the error's own properties.Reproduction
In situ this is reached via a normal
external_accountcredential whose subject token has expired: the STS response is aninvalid_grant,getErrorFromOAuthErrorResponse()converts it, and any downstreamerr.stack +=then crashes.Suggested fix
Leave
stackwritable (and non-enumerable) when copying, so these errors behave like ordinary ones:Simply not copying
stackat all would also work —newErroralready has its own accurate stack — though that loses the original call site. AlternativelynewError.cause = errconveys the same information using the standard mechanism and keepsstackuntouched.