[FEATURE REQ]Azure.Identity should handle token caching and refreshing when calling .GetTokenAsync just like AppAuthentication does

I was reading this documentation and getting ready to migrate from AppAuthentication to Azure.Identity.

While the new library surely works amazingly well with the new Azure client SDKs, I soon found out that the method to directly obtain access token, TokenCredential.GetTokenAsync, has the following warning:

// This method is called automatically by Azure SDK client libraries. You may call
// this method directly, but you must also handle token caching and token refreshing.

There are plenty of use cases where a managed identity access token needs to be explicitly retrieved. For example, using Entity Framework Core with either Azure SQL or Azure PostgreSQL with managed identity requires that the actual tokens to be passed to the EF provider. Same with authenticating against a custom Azure AD enterprise application via standard HttpClient.

These scenarios are unlikely to get native integration with Azure.Identity anytime soon.

The older library’s AzureServiceTokenProvider.GetAccessTokenAsync has built-in token caching and refreshing which works fairly well. It would be great if Azure.Identity can implement the same. Only then it will become a viable full replacement for AppAuthentication.

In the meantime, I believe this difference should be noted in the migration documentation under the “Access token retrieval” section.

[felinepc]

Dear awesome Microsoft engineers, by any chance we can give this a higher priority? I just did a search for “cache” on this repo and saw a long list of requests asking more or less the same thing:

Identity is a huge issue and we do NOT want to stick to the old library. Azure.Identity is not going to create libraries anytime soon for things like Azure SQL/Azure PostgreSQL/Azure App Service Microsoft Authentication, so we need to access this access token for the time being.

The old Azure.Services.AppAuthentication package works very reliably for this and has all the beautiful Microsoft-written caching logic built in. But as we all know since the old package is EOL, we’d really love to move to Azure.Identity, as Microsoft strongly suggested themselves. But we really do need this key feature implemented.

[felinepc]

@leidegre Sorry I started with EF Core and never used EF6, but it does appear to have IDbConnectionInterceptor? See this and this.

Yeah I know a simple in-memory cache and refresh logic wouldn’t take more than a few lines of code, but I just felt that the new package should have this built-in because the old one had it, and I generally trust MS’s internal implementation on this sort of things more than my own.