DefaultAzureCredential.get_token_info() cache fast-path is missing the hasattr() guard that ChainedTokenCredential applies

[loicdescotte]

• Package Name: azure-identity
• Package Version: 1.25.3 (also reproduced on 1.18.0 through 1.25.2, and current main)
• Operating System: Ubuntu 24.04 LTS
• Python Version: 3.12.3

Describe the bug
DefaultAzureCredential.get_token_info() has a cache fast-path that calls
get_token_info() on the previously successful credential without checking that the
credential actually implements it (azure/identity/_credentials/default.py, line 368 in 1.25.3):

if self._successful_credential:
    token_info = cast(SupportsTokenInfo, self._successful_credential).get_token_info(*scopes, options=options)

 ChainedTokenCredential.get_token_info()  guards the same situation with  hasattr()  and
falls back to  get_token() .  DefaultAzureCredential  overrides the method and drops that guard.

The consequence is order-dependent and easy to miss: when the chain resolves to a credential
that only implements the legacy  get_token()  protocol, the first call succeeds through the
guarded cold path and caches the credential, and every subsequent call raises  AttributeError .

This is not hypothetical. On Azure Databricks, setting  DATABRICKS_DEFAULT_SERVICE_CREDENTIAL_NAME 
makes the runtime inject a  ServiceCredentialTokenProvider  into the chain, and that provider
implements only  get_token() . Since azure-core's  BearerTokenCredentialPolicy  prefers
 get_token_info()  whenever the credential exposes it (azure-core >= 1.31.0), this breaks every
SDK client built on  DefaultAzureCredential  after the first token request.

To Reproduce

Self-contained, no Azure or Databricks account needed.  LegacyOnlyCredential  stands in for any
credential implementing only the legacy protocol:

from azure.core.credentials import AccessToken
from azure.identity import DefaultAzureCredential

class LegacyOnlyCredential:
    """Implements only the legacy get_token() protocol,
    like dbruntime.servicecredentials.ServiceCredentialTokenProvider."""
    def get_token(self, *scopes, **kwargs):
        return AccessToken("fake-token", 9999999999)

cred = DefaultAzureCredential()
cred.credentials = (LegacyOnlyCredential(),)

for i in (1, 2):
    try:
        info = cred.get_token_info("https://vault.azure.net/.default")
        print(f"call {i}: OK -> {info.token}")
    except AttributeError as e:
        print(f"call {i}: AttributeError -> {e}")

Output on 1.25.3:

call 1: OK -> fake-token
call 2: AttributeError -> 'LegacyOnlyCredential' object has no attribute 'get_token_info'

To Reproduce
Self-contained, no Azure or Databricks account needed.  LegacyOnlyCredential  stands in for any
credential implementing only the legacy protocol:

from azure.core.credentials import AccessToken
from azure.identity import DefaultAzureCredential

class LegacyOnlyCredential:
    """Implements only the legacy get_token() protocol,
    like dbruntime.servicecredentials.ServiceCredentialTokenProvider."""
    def get_token(self, *scopes, **kwargs):
        return AccessToken("fake-token", 9999999999)

cred = DefaultAzureCredential()
cred.credentials = (LegacyOnlyCredential(),)

for i in (1, 2):
    try:
        info = cred.get_token_info("https://vault.azure.net/.default")
        print(f"call {i}: OK -> {info.token}")
    except AttributeError as e:
        print(f"call {i}: AttributeError -> {e}")

Expected behavior

Both calls succeed. The fast-path should apply the same  hasattr()  fallback that
 ChainedTokenCredential.get_token_info()  already implements, i.e. fall back to  get_token() 
and wrap the result in  AccessTokenInfo  when the cached credential does not support
 get_token_info() .

Screenshots
N/A

Additional context
Versions:  get_token_info()  was added to  DefaultAzureCredential  in 1.18.0, and the unguarded
fast-path has been present since. 1.17.1 is unaffected because it does not implement
 get_token_info()  at all, so azure-core's own  hasattr()  guard in
 policies/_authentication.py  falls back to  get_token() .

This is not merely a consequence of injecting a custom credential. _successful_credential
is populated by two paths in ChainedTokenCredential: get_token_info() sets it after
checking hasattr(credential, "get_token_info"), but get_token() sets it (chained.py, line 131)
after checking only hasattr(credential, "get_token") (line 116). A credential cached through the
get_token() path is therefore guaranteed to implement only get_token, yet
DefaultAzureCredential.get_token_info() reads that same cache and calls get_token_info() on it
unconditionally. The class writes a weaker guarantee than the one it later relies on.

Workaround: pin  azure-identity<1.18 . Note that overriding  get_token_info()  in a
 DefaultAzureCredential  subclass is not a safe workaround on 1.17.1, because defining the
method makes azure-core's  hasattr()  check succeed again.

[github-actions]

Thank you for your feedback. Tagging and routing to the team member(s) best able to assist.

Generated by Agentic Triage for issue #48810 · 26.6 AIC · ⌖ 6.04 AIC · ⊞ 9.6K · ◷

[github-actions]

🎯 Agentic Issue Triage

Summary: DefaultAzureCredential.get_token_info() is missing the hasattr() guard on its cache fast-path, causing an AttributeError on the second call when the cached credential only implements the legacy get_token() protocol (not get_token_info()). This regresses on Azure Databricks when DATABRICKS_DEFAULT_SERVICE_CREDENTIAL_NAME is set.

📋 Issue Details

Package: azure-identity 1.25.3 (also reproducible on 1.18.0–1.25.2 and current main)
Affected API: DefaultAzureCredential.get_token_info() (azure/identity/_credentials/default.py, line ~368)
Scenarios:

• Any credential that only implements get_token() (not get_token_info()) is cached via the get_token() cold-path, then the fast-path in get_token_info() calls get_token_info() on it unconditionally — raising AttributeError on the second call.
• Confirmed broken in Azure Databricks when DATABRICKS_DEFAULT_SERVICE_CREDENTIAL_NAME injects a ServiceCredentialTokenProvider (legacy-only) into the chain.

Root ask: Apply the same hasattr() fallback in DefaultAzureCredential.get_token_info()'s fast-path that ChainedTokenCredential.get_token_info() already uses, falling back to get_token() and wrapping the result in AccessTokenInfo when the cached credential doesn't support get_token_info().

🔎 Debugging / Reproduction Notes

The root cause is in DefaultAzureCredential.get_token_info():

if self._successful_credential:
    token_info = cast(SupportsTokenInfo, self._successful_credential).get_token_info(*scopes, options=options)

There is no hasattr(self._successful_credential, "get_token_info") check before calling it. ChainedTokenCredential.get_token_info() (the parent class) already handles this correctly with hasattr + fallback to get_token().

The subtle issue: _successful_credential is populated by both get_token_info() (which checks hasattr) and get_token() (which only checks hasattr(credential, "get_token")), so a legacy-only credential can enter the cache through the get_token() path and then be called incorrectly through the get_token_info() fast-path.

Suggested investigation steps:

1. Confirm the fix: add hasattr(self._successful_credential, "get_token_info") check in DefaultAzureCredential.get_token_info() fast-path, mirroring the logic in ChainedTokenCredential.
2. Verify the provided self-contained reproduction script shows both calls succeeding after the fix.
3. Add a unit test covering a legacy-only credential cached through the get_token() path then called via get_token_info().

🏷️ Label Confidence

• Category: Client — azure-identity is a data-plane identity/authentication client library, not a management-plane library.
• Service: Azure.Identity — issue is explicitly about the azure-identity package, which maps to the %Azure.Identity service label per CODEOWNERS.
• Confidence: High — the package is unambiguous; category and service are clearly implied by the issue content and consistent with reference issues for this service.

👥 Owner Routing

• Matched CODEOWNERS entry: # ServiceLabel: %Azure.Identity (line 67) — exact match on predicted service label.
• AzureSdkOwners: @kashifkhan
• ServiceOwners: none listed (only /sdk/identity/ path owners @Azure/azure-sdk-write-identity)
• Routing action: Assigned @kashifkhan; added needs-team-attention because issue is customer-reported.
• Scan notes: Scanned bottom-to-top; skipped %Batch (line 71), stopped at %Azure.Identity (line 67) as first match.

Generated by Agentic Triage for issue #48810 · 26.6 AIC · ⌖ 6.04 AIC · ⊞ 9.6K · ◷