Best Practice for Setting MSAL Access Token

I’ve got a React application that is registered with a SPA configuration in Entra. Per the MSAL documentation, the default cache location is set to sessionStorage, this can be set to localStorage for reasons described here and discussed here, but I don’t do this in my MSAL configuration. Instead, in my handleRedirectPromise, I set the item key “accessToken” in my local storage to the token I receive from my MSAL auth callback. Then, using Axios Interceptors, I set the Authorization Header to the token stored in my local storage as so:

axios.interceptors.request.use(function (config) {
   config.headers.Authorization = localStorage.getItem('accessToken')
   return config;
});

I do this because without it, every time I reload the page, the authorization header that I originally was setting in my handleRedirectPromise via axios.defaults.headers.common[AuthConstants.AUTH_HEADER] assignment, would be erased and the value would be undefined.

So I tried accessing the token value from the cache location, but the token would be stored in an object with the key of the homeAccountId appended to other values which could be different every time a user logged in. For this reason, I don’t even bother changing my cacheLocation to localStorage in my MSAL configuration. Perhaps there’s a way to name the cache key in the MSAL configuration?

Anyways, doing it that way resulted in some janky code, so I tried the next option available, acquireTokenSilent. To be fair, I’m not sure how it should be organized into my code base as several demo examples have different implementations, but hardly any explanation for how the token is added to the header without either providing an existing logged in account or callback. But, as I’ve stated above, the page reload will erase the header, plus even if it weren’t erased, I’d still be relying on some user information to be stored because how else will I know if there is an active account if I don’t call the following during my handleRedirectPromise response:

msalInstance.setActiveAccount = res.account

So that I could run the following code before every HTTP request, found in this demo:

  if (!accessToken) {
      const account = instance.getActiveAccount();
      if (!account) {
          throw Error("No active account! Verify a user has been signed in and setActiveAccount has been called.");
      }

      const response = await instance.acquireTokenSilent({
          ...loginRequest,
          account: account
      });
      accessToken = response.accessToken;
  }

And I suppose I could use ssoSilent without any supplemental information as stated here to get and add my token to the header, but this implementation has a different purpose from what I’m trying to resolve.

As the title suggests, I’m concerned if what I’ve got working is best practice, or, more specifically, has some security risks that I should be considering. I appreciate any suggestions and advice you may have to offer. Thanks!