Summary
Add an opt-in (default-off) in-memory token cache to AzureCLICredential (and
AzureDeveloperCLICredential), e.g. a field on AzureCLICredentialOptions, consistent
with the existing opt-in Cache option already supported by other azidentity
credentials (client secret/cert, device code, interactive browser, workload identity, …).
Motivation
These credentials never cache (GetToken() invokes the CLI on every call), and azcore
caches tokens per-pipeline only. We understand this is by design (#23533) to always
reflect the tool's logged-in user, and we want to keep that as the default.
The gap is local development against large Azure environments. Production workloads
should use a service principal or managed identity (both cache fine, unaffected by this
request), but developers commonly use az login locally — and the documented mitigation,
"reuse client instances" (#25581), doesn't apply to applications that legitimately need
many distinct service clients (a separate client type per Azure service, scoped per
subscription). With az login, every cold pipeline re-execs az for the same scope.
For an application that enumerates resources across many Azure services, az is
re-executed so often that process startup dominates runtime. Adding an opt-in token cache
reduced end-to-end runtime by ~9x in our testing.
Why the suggested alternatives don't fit (for local dev)
- Reuse clients: not possible across distinct service client types / per-subscription clients.
- AzureDeveloperCLICredential: faster, but also doesn't cache (one
azd exec per acquisition) and needs a separate tool/login developers don't have.
- InteractiveBrowser / DeviceCode + persistent cache: changes the auth model away from
az login, needs app-level credential-selection flags, and authenticates a separate MSAL identity rather than reusing the developer's existing CLI session.
Proposal
An opt-in cache, off by default, so the by-design behavior is unchanged unless a caller
explicitly enables it and accepts the identity-switch caveat from #23533 (acceptable when
the logged-in identity is fixed for the process lifetime). Cache key by scope + tenant +
claims; refresh before expiry. Happy to contribute a PR if the team is open to it.
References
Summary
Add an opt-in (default-off) in-memory token cache to
AzureCLICredential(andAzureDeveloperCLICredential), e.g. a field onAzureCLICredentialOptions, consistentwith the existing opt-in
Cacheoption already supported by other azidentitycredentials (client secret/cert, device code, interactive browser, workload identity, …).
Motivation
These credentials never cache (
GetToken()invokes the CLI on every call), and azcorecaches tokens per-pipeline only. We understand this is by design (#23533) to always
reflect the tool's logged-in user, and we want to keep that as the default.
The gap is local development against large Azure environments. Production workloads
should use a service principal or managed identity (both cache fine, unaffected by this
request), but developers commonly use
az loginlocally — and the documented mitigation,"reuse client instances" (#25581), doesn't apply to applications that legitimately need
many distinct service clients (a separate client type per Azure service, scoped per
subscription). With
az login, every cold pipeline re-execsazfor the same scope.For an application that enumerates resources across many Azure services,
azisre-executed so often that process startup dominates runtime. Adding an opt-in token cache
reduced end-to-end runtime by ~9x in our testing.
Why the suggested alternatives don't fit (for local dev)
azdexec per acquisition) and needs a separate tool/login developers don't have.az login, needs app-level credential-selection flags, and authenticates a separate MSAL identity rather than reusing the developer's existing CLI session.Proposal
An opt-in cache, off by default, so the by-design behavior is unchanged unless a caller
explicitly enables it and accepts the identity-switch caveat from #23533 (acceptable when
the logged-in identity is fixed for the process lifetime). Cache key by scope + tenant +
claims; refresh before expiry. Happy to contribute a PR if the team is open to it.
References