Hi @Matthew Vacarro ,
Thanks for reaching out.
Your understanding is correct here. In-memory caches are good for applications that don't require tokens to persist between app restarts which is mainly for local app development.
For token persistence, MSAL provides and recommended to use distributed token cache (Redis, SQL Server, Azure Cosmos DB, distributed memory) to request tokens for users in a production application.
A distributed memory cache will not clear when the app stops. In this case, the cached items are stored by the app instance on the server where app is running. The Distributed Cache is just an abstraction (using IDistributedCache interface). Using Distributed cache, you can inject the cache where you want to store and use. Asp.net currently support
• Distributed Memory Cache -This one is an in memory cache, likely works the same that when you do AddInMemoryCache.
• Distributed SQL Server cache -allows the distributed cache to use a SQL Server database as its backing store.
• Distributed Redis cache
• Distributed NCache cache
Also, if you want to create your own implementation of the IDistributedCache interface you use any other store (mysql, CosmosDb…)
Refer Token cache serialization (MSAL.NET) for detailed description on distributed cache and sample framework-provided implementations.
Also, Client credential flow is OAuth flow commonly used for server-to-server interactions that usually run in the background, without immediate interaction with a user and help to acquire the token and call protected web APIs.
Hope this will help. If you have further questions on this, please let us know.
Thanks,
Shweta
-----------------------------------------------
Please remember to "Accept Answer" if answer helped you.
Hi @Matthew Vacarro ,
Sorry for the confusion here.
You can use distributed redis cache with node.js / express application as well.
Refer ExpressTestApp sample, which has an distributed cache implementation
As you have user sign in, you can use authorization code flow (OAuth flow) which need a user interaction to get the token.
OAuth flows are used to get the access token and refresh token from token endpoint to securely call the Microsoft graph API or other protected APIs. No OAuth flow will hold the token forever.
Access token lifetime are short lived and refresh tokens can be used to acquire new access tokens.
However, Refresh token MaxInactiveTime will be 90 days and MaxAgeMultiFactor will be until revoked. So, if are using the refresh token every hour to get new access token, means the refresh token should not expire as MaxInactiveTime of 90 days will never met and you will be able to hold the token until logged out as per your scenario.
Hope this helps.
Thanks,
Shweta
----------------------------------------
Please do not forget to "Accept the answer" wherever the information provided helps you to help others in the community.
Thanks again @Shweta Mathur !
Last questions, in the implementation used above in "ExpressTestApp" the author creates a wrapper instance of the MSAL
I tried doing the same thing using the default MSAL
using the default MSAL instance creation it seems you can't update the tokenCache.persistence. Or at least when I tried it didn't work. Where is this "msalWrapper" being created? Does this need to be created to update the persistence? I haven't found a file for it and when I looked in the package.json I found this
I've never seen it before in a package.json so I am unsure whats happening.
Thanks again for all your help!
Cheers,
Matt
Hi MatthewVacarro-4577,
The wrapper around MSAL is to automate basic authentication and authorization tasks. It is simple wrapper example around MSAL Node ConfidentialClientApplication class for Express MVC web apps.
It has nothing to do with persistence cache.
For Caching, This example also has a feature persistent cache plugin in order to save the cache to disk where it is using distributed caching pattern to persist MSAL's token cache via Redis.
Thanks,
Shweta
-----------------------------------------------
Please do not forget to "Accept the answer" wherever the information provided helps you to help others in the community.
Gotcha, thats helpful to know. So why wouldn't my persistence update when passing the same function to the default MSAL?
I can confirm:
However, it's not getting the second string passed (sessions Id) by the
initializeTokenCachePlugin
. Why? Other than the wrapper I am doing it it exactly the way the example shows but it's just never updating the persistent functions and the first argumentHi @Matthew Vacarro , Are you saying its not storing the sessionId in cache? or it is not retrieving from the cache?
This seems to be troubleshoot line by line to check how data has been stored and retrieved from Redis in a proper way.
Thanks,
Shweta
Sign in to comment