Feature request
Support client-side Credential Access Boundaries in google-auth-library-nodejs — the equivalent of Java's ClientSideCredentialAccessBoundaryFactory.
Background
The Node library ships the server-side DownscopedClient, which performs one STS token exchange per downscoped token. Google's IAM documentation (Create a downscoped credential) now describes the client-side approach — exchange once for an access boundary intermediary token, then mint downscoped tokens locally with varying boundary rules, no STS round trip per token — and calls it "the recommended approach because it provides better performance, scalability, and future feature compatibility."
Today that implementation exists only in Java (cab-token-generator module, ClientSideCredentialAccessBoundaryFactory). Searching the googleapis org, there is no Node, Python, or Go implementation and no open tracking issue, so filing this one for Node.
Use case
A token broker minting many unique prefix-scoped Cloud Storage tokens at high frequency: per-tenant object-name prefixes, one short-lived token per tenant session. With the server-side DownscopedClient, every unique boundary costs an STS exchange against the sts.googleapis.com token-exchange quota (6,000/project/minute). Caching per tenant helps, but fresh-mint demand scales with distinct active tenants; client-side minting removes the ceiling entirely, as the docs note.
Questions
- Is client-side CAB support planned for
google-auth-library-nodejs? Any timeline?
- If it is not planned soon: is the intermediary-token wire format (the protobuf-encoded boundary + encryption scheme visible in Java's
cab-token-generator) considered stable and supported for third-party client implementations, or is it internal and subject to change?
Environment
google-auth-library 10.x on Node 24 / Bun, tokens consumed by Cloud Storage JSON/XML APIs.
Feature request
Support client-side Credential Access Boundaries in
google-auth-library-nodejs— the equivalent of Java'sClientSideCredentialAccessBoundaryFactory.Background
The Node library ships the server-side
DownscopedClient, which performs one STS token exchange per downscoped token. Google's IAM documentation (Create a downscoped credential) now describes the client-side approach — exchange once for an access boundary intermediary token, then mint downscoped tokens locally with varying boundary rules, no STS round trip per token — and calls it "the recommended approach because it provides better performance, scalability, and future feature compatibility."Today that implementation exists only in Java (
cab-token-generatormodule,ClientSideCredentialAccessBoundaryFactory). Searching the googleapis org, there is no Node, Python, or Go implementation and no open tracking issue, so filing this one for Node.Use case
A token broker minting many unique prefix-scoped Cloud Storage tokens at high frequency: per-tenant object-name prefixes, one short-lived token per tenant session. With the server-side
DownscopedClient, every unique boundary costs an STS exchange against thests.googleapis.comtoken-exchange quota (6,000/project/minute). Caching per tenant helps, but fresh-mint demand scales with distinct active tenants; client-side minting removes the ceiling entirely, as the docs note.Questions
google-auth-library-nodejs? Any timeline?cab-token-generator) considered stable and supported for third-party client implementations, or is it internal and subject to change?Environment
google-auth-library10.x on Node 24 / Bun, tokens consumed by Cloud Storage JSON/XML APIs.