Allow specifying custom TokenCache

[aloneguid]

This library doesn't allow specifying custom TokenCache, always defaulting to TokenCache.Default. This is OK when working with non-expiring credentials (i.e. service principal) but doesn't work when tokens need to be persisted.

[msftclas]

All CLA requirements met.

[azuresdkci]

Can one of the admins verify this patch?

[qub1n]

This pull request is a very good idea.

[yaohaizh]

@aloneguid Thanks for your contribution!

[weidongxu-microsoft]

I think it looks good.

The DefaultShared would cache the token in memory.

@aloneguid Would you share a bit of your use case? Do you persist the token for later use, or for parellel use across process?

[eosfor]

I wonder if this could help to reuse the token cache from an external context. for example, I'm making a PowerShell cmdlet using Fluent SDK. I want to use this cmdlet along with other cmdlets provided by AZ module. In theory, I could try to reuse the AZ module token cache after it is authenticated, so I do not need to authenticate twice, once for the AZ module, and the second time for my Fluent cmdlet.

Or there is another way to reuse the cache?

@weidongxu-microsoft, what do you think?

[weidongxu-microsoft]

@eosfor

I think the rationale underlying not sharing the token credential is mostly for security reason. The authenticate itself is not costly (maybe 1 additional request per hour?).

The AzureCredentials class itself is public. So it might be easier to extend the class and override ProcessHttpRequestAsync?

[qub1n]

My rationale behind it is that we have multitenant application. The app is used by amny users which access different tenants and different subscriptions based on roles and accounts.

Thats why the app use multiple credentials to access multiple tenants/subscription.

Currently if there is only one shared token cache, we have to solve security boundary by application logic which is quite britle.

I would prefer to have security boundary by architecture, this mean to have token cache by user role or something similar.

[weidongxu-microsoft]

@qub1n

Will this PR solve your use case? If so, I will merge it.

[eosfor]

Hi @weidongxu-microsoft , basically my problem is here or here. I tried to overcome this by sharing the AZ cache, but there are other changes necessary to make this all work. It seems like there are conflicting Auth libraries used in the AZ find Fluent, so they cannot be easily loaded into the pwsh process and some other things. But this PR will be just a part of the solution I think. But maybe, together with the AZ module team you could find some other way to make it.