Allow to disable encryption of localStorage

[JanStevens]

Core Library

MSAL.js (@azure/msal-browser)

Wrapper Library

MSAL React (@azure/msal-react)

Public or Confidential Client?

Public

Description

Hi,

We use msal-react in a capacitor app (mobile), we noticed that upgrading to latest msal v4 and msal-react v3 that the localStorage is now being encrypted with a session token.

This means for mobile apps that from the moment you put the app to the background, the session is removed and you have to login again which makes the app completely unusable.

I would suggest to add a setting to disable the encryption (with proper warnings / indications / remarks) specifically for this case.

Regards

[sameerag]

This is a feature by design, added for security. Why does ssoSilent not work as you should have a session in the background without prompting the user to explicitly use interaction?

[JanStevens]

This is a feature by design, added for security. Why does ssoSilent not work as you should have a session in the background without prompting the user to explicitly use interaction?

We are using msal react in a capacitor app. This works by having a native process which serves the web app to a web view.

Everytime the app moves to the background the session is ended so all session data is removed.

If the app moves to the foreground there are tokens but they are encrypted without a session key so they have to login.

Are you implying that we should just call ssoSilent whenever the app comes to the foreground? 🤔

[karpikpl]

It looks like this might be affecting our playwrigt tests - we save MSAL state to re-use in every test.
It seems that with encrypted storage, we won't be able to re-use auth state to execute tests.

[Adam-Wallenrod]

It looks like this might be affecting our playwrigt tests - we save MSAL state to re-use in every test. It seems that with encrypted storage, we won't be able to re-use auth state to execute tests.

Dealing with the same issue in playwright tests.

[JanStevens]

My hacky workaround using patch-package so the encryption key is also stored in local storage.

diff --git a/node_modules/@azure/msal-browser/dist/cache/LocalStorage.mjs b/node_modules/@azure/msal-browser/dist/cache/LocalStorage.mjs
index 0c0d195..35bccf2 100644
--- a/node_modules/@azure/msal-browser/dist/cache/LocalStorage.mjs
+++ b/node_modules/@azure/msal-browser/dist/cache/LocalStorage.mjs
@@ -6,7 +6,6 @@ import { base64DecToArr } from '../encode/Base64Decode.mjs';
 import { urlEncodeArr } from '../encode/Base64Encode.mjs';
 import { createBrowserAuthError } from '../error/BrowserAuthError.mjs';
 import { createBrowserConfigurationAuthError } from '../error/BrowserConfigurationAuthError.mjs';
-import { SameSiteOptions, CookieStorage } from './CookieStorage.mjs';
 import { MemoryStorage } from './MemoryStorage.mjs';
 import { getAccountKeys, getTokenKeys } from './CacheHelpers.mjs';
 import { StaticCacheKeys } from '../utils/BrowserConstants.mjs';
@@ -33,8 +32,7 @@ class LocalStorage {
     }
     async initialize(correlationId) {
         this.initialized = true;
-        const cookies = new CookieStorage();
-        const cookieString = cookies.getItem(ENCRYPTION_KEY);
+        const cookieString = this.getItem(ENCRYPTION_KEY);
         let parsedCookie = { key: "", id: "" };
         if (cookieString) {
             try {
@@ -65,10 +63,7 @@ class LocalStorage {
                 id: id,
                 key: keyStr,
             };
-            cookies.setItem(ENCRYPTION_KEY, JSON.stringify(cookieData), 0, // Expiration - 0 means cookie will be cleared at the end of the browser session
-            true, // Secure flag
-            SameSiteOptions.None // SameSite must be None to support iframed apps
-            );
+            this.setItem(ENCRYPTION_KEY, JSON.stringify(cookieData))
         }
         // Register listener for cache updates in other tabs
         this.broadcast.addEventListener("message", this.updateCache.bind(this));

IMO the encryption gives a false sense of security. Yes local storage is "encrypted" but if an attacker manages extract your local storage then they obviously can also extract javascript session cookies so you back at the start.