[Feature Request]: Expose MSAL caching services to be used by external services

[henriblMSFT]

Is your feature request related to a problem? Please describe.
Azure.Identity is a library to retrieve bearer token for azure managed identities. It does not currently expose a cache as mentioned in their documentation.

To fetch token reliably consumers of the Azure.Identity need to implement the caching logic with all the complexity that comes with managing refresh tokens, temporary outages, accessing different scopes and more.

Most of this logic is already present in the Microsoft.Identity.Client library but the Cache itself cannot be used as a standalone service. It is automatically used when fetching tokens directly from Azure Active Directory. Because Azure.Identity calls a service that is hosted on the virtual machine the MSAL library cannot be used to retrieve a token for a managed

Describe the solution you'd like
Expose the Caching services so that they can be used independently of the ConfidentialClientApplicationBuilder

Describe alternatives you've considered
Re-implementing the cache mechanism on our side which while doable is quite complex and time consuming. It is unlikely to be as robust as code that's used by thousands of other libraries.

A similar feature request has been made to the Azure.Identity library. But they mentioned that they would like to use the MSAL library caching services instead of re-building their own.

[jmprieur]

@henriblMSFT

• If I understand correctly you'd want to use the token cache independently of MSAL.NET as a separate service (maybe DLL?)
• There are discussions so that MSAL supports MSI directly (and it does already get to some MSI endpoints for Regional). This seems to be simpler? what do you think?

[henriblMSFT]

If MSAL had support for MSI that would also solve the problem.

One scenario I'm not sure is covered is the fallback authentication mechanism that Azure.Identity has when using DefaultAzureCredential. If the ManagedIdentity service is not available it will try alternate means to obtain an auth token. This is quite useful to allow developers to run a project locally. Since they don't have access to a managed identity they need to fallback to their user identity to authenticate to external resources.

[qetza]

Hi @jmprieur,
I found this issue while trying to deal with MSI and caching in Azure.Identity and seeing that no cache was provided 😞

As @henriblMSFT says using Azure.Identity is not only for support of MSI but also for its support of fallback authentication mechanism. As developers are developing and testing locally without MSI, the DefaultAzureCredential class allows them to work without having to deal with different authentication between local and azure.

Exposing the MSAL cache class so that it can be used by external libraries is one solution, another would be to add MSI support to MSAL and fallback mechanism as in Azure.Identity.

[jmprieur]

@qetza @henriblMSFT

• Azure.Identity is going to add support for OBO, and therefore will leverage MSAL cache.
• We also have discussions for MSAL to support MSI.

[qetza]

@jmprieur, will Azure.Identity leverage MSAL cache for authentication mechanism (MSI, VS, Azure CLI...) or only for OBO flow? If it's only for OBO, it's a start but i think that what we would like is to have integrated caching for all mechanism 😄

[jmprieur]

that's more a question for the Azure SDK team, @qetza.

[bgavrilMS]

MSAL is building support for Managed Identity - see a preview in 4.49.1
Azure SDK already uses MSAL's token cache via AppTokenProvider delegate.