[Documentation] Use of ConfidentialClientApplication and TokenStore

Documentation Related To Component:

ConfidentialClientApplication and TokenStore

Please check those that apply

• typo
• documentation doesn’t exist
• documentation needs clarification
• error(s) in example
• needs example

Description Of The Issue

I have a question regarding the use of the ConfidentialClientApplication and token caching that is not very clear in the documentation.

In my application, I’m using the on behalf of flow to call downstream API from my ASP.NET Core Web API and I would like to leverage token caching for users.

1. The current documentation for MSAL states that there is a default token caching implemented, however it is not very clear in the following cases:

• How and when should the ConfidentialClientApplication be instantiated. When ConfidentialClientApplication is registered as a singleton in the DI service provider the default token store can be used as expected and subsequent calls from the same user will result in only one call to Azure AD (when using the AcquireTokenSilent on the ConfidentialClientApplication). However registering it as a scoped service the cache is only available per request. My question is: Is it safe to register ConfidentialClientApplication as singleton? Can you please update and elaborate on this in the https://github.com/AzureAD/microsoft-authentication-library-for-dotnet/wiki/Client-Applications with this information?
• Is the default token store handling removal of accounts and tokens when they expire?
• On the other hand, for the on behalf of flow the documentation states that you should consider implementing your own cache. Can you please elaborate the reasons for this recommendation? It will be much easier to implement it if we can understand the reasons and use cases.

1. There is a proposal for creating Microsoft.Identity.Client.Extensions.Web as NuGet package (https://github.com/AzureAD/microsoft-authentication-extensions-for-dotnet), the code base has examples on how to implement token store per user, but the implementation is not following some of the best practices from the ASP.Net Core team (the code base leaks lot of framework dependencies like the IHttpContextAccessor, HttpContext and forces use of ISession). There is a lot of repeating code when using the MSAL library and it is good that such library be created, but it does not look that is production ready.

Looking forward on your feedback! Thank you! 😃

[bgavrilMS]

Great questions.

1. You should have 1 Confidential Client Application for each token cache. And we recommend that you have 1 token cache per session, so there should be 1 CCA per session.

Creation pattern in web app sample.

Testing caveat: You may think that using DI is also gonna make things more testable. Sadly, it’s difficult (impossible) to mock the builder pattern, so I would actually suggest to wrap the creation and invocation in a class of your own.

1. Default token cache is a non-static in-memory implementation (think of it as a dictionary). There is one for each ConfidentialClientApplication you create. If you create multiple applications, you’d need to attach the same cache to each of them (some of our samples do that)

The issues with the in-memory cache are:

• Availability - in memory token caches are fine, but when ASP renews the process, it will kill the cache. I’m not sure how much control you have over that. Now OBO itself is a silent flow, so there is no user impact if you just get a fresh token from AAD. However, getting the original token via the authorization flow is impactful - your users will need to re-login. The solution is to use a persistent cache like a Redis or SQL cache

• Security - although we test MSAL as best we can to protect it against it retrieving the token of the wrong user, a token cache implementation where you store only 1 user per cache is more secure by default.

Scale - a distributed cache scales better. A rough example of how much space is needed - around 50kb for some 3 users in an OBO like scenario.

Microsoft.Identity.Client.Extensions.Web has a bunch of TokenCache implementation that you can use.

1. We’re still talking internall about the best way to productize Microsoft.Identity.Client.Extensions.Web. For now, we recommend that you just copy the code.

CC @kalyankrishna1 @TiagoBrenck @jmprieur

[bgavrilMS]

Hi yes, it is finished. https://github.com/AzureAD/microsoft-identity-web has GA-ed and it offers all the best practices for this scenario.