Token cache persistance with CAE disabled

[danijel3]

• Package Name: azure-identity
• Package Version: 1.24.0
• Operating System: Linux
• Python Version: 3.13.7

Describe the bug

Using token cache persistence causes problems on Linux with CAE disabled.

To Reproduce

token_cache_options = TokenCachePersistenceOptions(name="MyApp")

if Path("cred.json").exists():
    with open("cred.json", "r") as f:
        deserealized_record = AuthenticationRecord.deserialize(f.read())

    device_credential = DeviceCodeCredential(
        client_id=azure_settings["clientId"],
        tenant_id=azure_settings["tenantId"],
        authentication_record=deserealized_record,
        cache_persistence_options=token_cache_options,
        disable_automatic_authentication=True,
    )
else:
    device_credential = DeviceCodeCredential(
        client_id=azure_settings["clientId"],
        tenant_id=azure_settings["tenantId"],
        cache_persistence_options=token_cache_options,
        disable_automatic_authentication=True,
    )

    record = device_credential.authenticate(scopes=azure_settings["graphScope"])

    with open("cred.json", "w") as f:
        f.write(record.serialize())

app_client = GraphServiceClient(
    credentials=device_credential, scopes=azure_settings["graphScope"]
)

# do something with app_client, eg: `app_client.me.get()`

The code above will fail on second run (on silent authentication) because the getToken method won't be able to find the token cache on disk. This is because, by default, the enable_cae attribute is set to False and this causes the first run (interactive authentication) to create a cache file on disk called ~/.IdentityService/<NAME>.nocae, whereas the second (ie. silent) run will have the CAE set by default to True (due to a bug described below), which will cause the system to think there is no cache present and fail.

This can be resolved by setting the enable_cae attribute to True in the authenticate method, thus creating a file called ~/.IdentityService/<NAME>.cae, which makes everything work okay:

record = device_credential.authenticate(scopes=azure_settings["graphScope"], enable_cae=True)

The main issue is that currently it is impossible to create a persistent cache without CAE in this scenario. This is because the AzureIdentityAuthenticationProvider class has enable_cae set to True by default (even though everywhere else it's set to False) and there is no facility to change this default setting when initializing the GraphServiceClient.

Suggested resolutions

1. add information in documentation and tutorials about how CAE affects the persistent token cache on Linux
2. add a facility to change the CAE flag in GraphServiceClient (eg. add enable_cae attribute to the class's initialization routine)

[xiangyan99]

@pvaneck could you help to take a look?

[pvaneck]

Thanks for the feedback. For context, we maintain two caches, since each cache treats tokens independently of their claims. If CAE-enabled and non-CAE tokens were stored together, they could overwrite one another—leading to inconsistent behavior and potential security issues with "weak" tokens overwriting "strong" tokens.

We are moving towards CAE-enabled by default across our SDKs, so soon, most caching will be done in the *.cae cache.

For your suggestions:

1. I agree that we should improve the documentation regarding CAE and caching. I will make it a work item to update our TOKEN_CACHING.md document and any other pertinent docs.
2. This client is not maintained in this repo (appears to be maintained here)

[danijel3]

I will post the suggestion on updating the GraphServiceClient in its repo.

Just would like to reiterate one of my points:

• the DeviceCodeCredential.authenticate (in fact it's defined in the InteractiveCodeCredential.getToken used a bit later down the line) has enable_cae set to False
• at the same time the AzureIdentityAuthenticationProvider used internally by GraphServiceClient has its is_cae_enabled set to True

If these arguments aren't set explicitly, the code will simply fail to work properly. Would be a good idea to unify this parameter across all the classes to avoid confusion.