Add an option to use a custom MSAL Cache

[eskaufel]

This implementation requires HttpContextAccessor, and DistributedMemoryCache (In memory distributed cache can cause strange behavior unless the web server has sticky sessions).

According to the Asp.Net documentation the session data is considered ephemeral data—the site should continue to function without the session data. Critical application data should be stored in the user database and cached in session only as a performance optimization.

The session data is by default reset after 20 minutes of inactivity. Sessions states are maintained by a cookies with a session id, these are not shared across browsers and they are deleted when the browser sessions end. However, the authentication cookie can last longer causing unfortunate issues as the token is only configured at OnAuthorizationCodeReceivedAsync. This will make the user unable to use the services without logging out and back inn again.

I can continue, but in short the implementation is bad and should be replaced.

[mingderekwang]

Hello, yes, you are right, actually we also have this concern for a long time, but we do have some cases from customer that they only have session to store the user data, which is not good. We have the schedule to update this part form last year, but not prioritized. For the session id in MASL cache, it is not ideal and fit for only has session to store the token cache, I will not recommend you to use this one if you have external storage like Redis or SQL, and we will try to prioritize this ASAP. Please also submit the pull request if you want to contribute, thanks.

[eskaufel]

I agree that there are no obvious generic solutions as a persistent store is required. I suppose the first step would be to abstract the tokencache implementation to make it possible to use a custom implementation.