Open rymeskar opened 3 years ago
@rymeskar, I'm a bit confused by the question. I believe we already provide extension methods to use the token cache with MSAL directly: https://docs.microsoft.com/en-us/azure/active-directory/develop/msal-net-token-cache-serialization?tabs=aspnet#distributed-caches
(in Microsoft.Identity.Web.TokenCache)
@jmprieur the current API re-initialize the ServiceCollection
from scratch. My proposal is that the user has already registered the Microsoft.Extensions.* caches into his DI (ServiceProvider
) already at app startup. IMHO Id.Web should provide a way to work with such ServiceProvider as well. Not just this from-scratch way.
@rymeskar : I'm still confused. Do the following work?
and
?
These are useful at startup (IServiceCollection).
The missing signature I had in mind is:
public static IConfidentialClientApplication AddInMemoryTokenCache( this IConfidentialClientApplication confidentialClientApp, IServiceProvider serviceProvider)
etc.
It seems like you already today provide the customer the option to register the caches to service collection. You are also creating a separate caching package without the ITokenAcquisition API.
The user might take advantage of the native pattern of registrations the cache implementation to DI. But then the actual cca/cache glue code is provided only within the TokenAcquistion APIs [1,2] not on CCA extension methods.
Could you maybe add an extension to IConfidentialClientApplication method that expects IServiceProvider and another one that directly expects IMsalTokenCacheProvider so that customers can