Persist Token Cache or Better Solution

Matthew Vacarro 1

Node / Express Server & PG DB

MSAL is instantiated when the server builds and is held in App.locals

=> app.locals.msalClient = new msal.ConfidentialClientApplication(msalConfig);

Everything works great, when I user login all the information is held in the MSAL and the tokens are accessible.

Here's the problem: every time I want to push any updated to prod the cache of tokens are lost due to being held in local memory. So when I rebuild local or on Heroku the cache is empty and that requires my users to re-auth. I need these tokens to persist but there doesn't seem to be a way for me to add them into the DB to rehydrate or leverage later. From my understanding, MSAL won't allow you to insert tokens back in.

The service I am building runs a lot in the background and shouldn't require a user having to open the application for the service's protocols to continue.

I looked into doing the "Client credential flows" but I can only find explanations in .NET. Ideally, I would love for the tokens to be held on the Azure close and stay accessible & persistent. However I am happy to hear any and all solutions.

Thanks,
Matt

1 answer

Shweta Mathur 27,381 Reputation points Microsoft Employee

2022-02-03T10:57:51.797+00:00

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.
Please sign in to rate this answer.
Matthew Vacarro 1 Reputation point

2022-02-03T17:36:23.49+00:00

@Shweta Mathur Thanks so much, I have a few questions

...inject the cache where you want to store and use. Asp.net currently support"

Does this mean I can't use this on a Node.js server? If not what is the workaround?
Do you recommend using Client Credential Flow over the current flow I am using (User signs in once and I hold their data/token until they asked to be logged out)

Thanks for the very quick response <3

Cheers,
Matt

Shweta Mathur 27,381 Reputation points Microsoft Employee

2022-02-05T04:11:16.667+00:00

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.

Matthew Vacarro 1 Reputation point

2022-02-08T23:05:45.82+00:00

Thanks again @Shweta Mathur !

Last questions, in the implementation used above in "ExpressTestApp" the author creates a wrapper instance of the MSAL

const msalWrapper = require('msal-express-wrapper/dist/AuthProvider'); const authProvider = new msalWrapper.AuthProvider(appSettings, cachePlugin); function initializeTokenCachePlugin(req, res, next) { const cachePlugin = require('./utils/cachePlugin')(persistenceHelper, req.session.id); authProvider.msalClient.tokenCache.persistence = cachePlugin; next(); }

I tried doing the same thing using the default MSAL

const MSAL = new msal.ConfidentialClientApplication(msalConfig);

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

"dependencies": { ... "msal-express-wrapper": "file:../" },

I've never seen it before in a package.json so I am unsure whats happening.

Thanks again for all your help!
Cheers,

Matt

Shweta Mathur 27,381 Reputation points Microsoft Employee

2022-02-09T10:07:34.647+00:00

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.

Matthew Vacarro 1 Reputation point

2022-02-09T20:41:13.26+00:00

Gotcha, thats helpful to know. So why wouldn't my persistence update when passing the same function to the default MSAL?

// Among other things these are the imported helpers const persistenceHelper = require("./logic/util/persistenceHelper")(redisClient); const cachePlugin = require("./logic/util/cachePlugin")(persistenceHelper, "fooBar"); const msalConfig = { auth: {...}, cache: { cachePlugin, // <= Custom Plugin }, system: {...}, }; const authProvider = new msal.ConfidentialClientApplication(msalConfig); // Helper function to update the cache plugin to have a session ID to look up in Redis function initializeTokenCachePlugin(req, res, next) { const cachePlugin = require("./logic/util/cachePlugin")(persistenceHelper, req.sessions.id); authProvider.tokenCache.persistence = cachePlugin; next(); } app.use(initializeTokenCachePlugin);

I can confirm:

The Cache persistence shows up in the msal instance

The cache plugin is getting the first string passed ("fooBar")

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 argument

Shweta Mathur 27,381 Reputation points Microsoft Employee

2022-02-16T10:12:54.443+00:00

Hi @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