[Identity] Fix issue with token requests with claims

[pvaneck]

Some credentials do not bypass the token cache when a get_token/get_token_info call is made with claims provided. This can cause issues when the credential continues to serve an insufficient token. This change updates the credentials where this is an issue.

[xiangyan99]

Should we let msal handle cache with claims?

[Copilot]

Pull request overview

This PR fixes a token caching issue where certain Azure Identity credentials were not bypassing the cached access token when claims are provided in get_token or get_token_info calls. This could result in serving an insufficient token that doesn't meet the required claims. The fix ensures that when claims are specified, credentials always request a new token from the authentication service instead of returning a cached one.

• Added cache bypass logic in AadClientBase.get_cached_access_token to return None when claims are provided
• Updated SharedTokenCacheCredential (sync and async) to skip the cached access token lookup when claims are present
• Added comprehensive test coverage for both the base client and credential implementations

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated no comments.

Show a summary per file

File	Description
sdk/identity/azure-identity/azure/identity/_internal/aad_client_base.py	Added early return in get_cached_access_token when claims are provided, ensuring all credentials using this base class skip the cache
sdk/identity/azure-identity/azure/identity/_credentials/shared_cache.py	Modified _get_token_base to conditionally skip cache lookup when claims are present
sdk/identity/azure-identity/azure/identity/aio/_credentials/shared_cache.py	Applied the same cache bypass logic in the async version of SharedTokenCacheCredential
sdk/identity/azure-identity/tests/test_aad_client.py	Added test verifying that get_cached_access_token returns None when claims are provided
sdk/identity/azure-identity/tests/test_shared_cache_credential.py	Added test ensuring SharedTokenCacheCredential bypasses cache and uses refresh token when claims are provided
sdk/identity/azure-identity/tests/test_shared_cache_credential_async.py	Added async version of the SharedTokenCacheCredential claims bypass test
sdk/identity/azure-identity/CHANGELOG.md	Documented the bug fix with a reference to the PR

[pvaneck]

Should we let msal handle cache with claims?

I recall there being a discussion regarding this and it being determined that MSAL is agnostic of token claims by design. Internally, MSAL doesn't check the cache when a claims challenge is provided. This is following suit with the non-MSAL based credentials.

[xiangyan99]

Should we let msal handle cache with claims?

I recall there being a discussion regarding this and it being determined that MSAL is agnostic of token claims by design. Internally, MSAL doesn't check the cache when a claims challenge is provided. This is following suit with the non-MSAL based credentials.

Yes. Today our logic is

if we receive a claim:
    drop the cache and call msal to get another token
    msal caches the new token

I am considering delegating this logic to MSAL, allowing it to determine whether to cache the token with claim information in the future.

[pvaneck]

Yes. Today our logic is

if we receive a claim:
    drop the cache and call msal to get another token
    msal caches the new token

For MSAL-based credentials, the logic is more akin to:

If we receive a claims challenge:
    skip access token cache check
    try using refresh token (if available) with claim or send new token request with claim
    cache new token, overriding old one

I am considering delegating this logic to MSAL, allowing it to determine whether to cache the token with claim information in the future.

There is a logic for the above already in MSAL, but here, we are just determining whether to check the cache or not, as the MSAL cache is the only MSAL API we use for these specific credentials.