Microsoft-authentication-library-for-js: New Secure Option For Storage

[DarylThayil]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[x] Feature request
[ ] Documentation issue or request
[ ] Other... Please describe:

Browser:

• [ ] Chrome version XX
• [ ] Firefox version XX
• [ ] IE version XX
• [ ] Edge version XX
• [ ] Safari version XX

Library version

Library version: X.Y.Z

Current behavior

Msal js currently supports localStorage and sessionStorage for cache. We would like to add other options, including a customer managed storage. This would let the app serialize their cache state and potentially share with other platforms

Expected behavior

Minimal reproduction of the problem with instructions

[RobMaskell]

I arrived here also looking for secure storage of the access tokens, it seems that local and session storage right now don't acheive that. I saw the two items https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/602 and https://github.com/AzureAD/microsoft-authentication-library-for-js/issues/637 had been closed and I'm assuming this is the item for future options? According to https://github.com/OWASP/CheatSheetSeries/blob/master/cheatsheets/JSON_Web_Token_Cheat_Sheet_for_Java.md#token-storage-on-client-side it is possible to make sessionstorage secure by adding fingerprinting although by the looks of it this would require changes to AAD to add the fingerprint to the token as well as MSAL.js to check it but might be an option for consideration?

[rnarayana]

Any recommendations here? I also arrived looking for secure storage other than localStorage.

[NickLiffen]

Hey 👋 Just wanted to follow up here and see if there was any traction on this issue. We are somewhat moving away from session/local storage for SPA's and client run applications and more moving towards HTTP Cookies/Web Workers. As mentioned above, I am looking at issues #602 and #637 which all have been closed, but not resolution?

This article: Storing Tokens is a great article which documents some of the pros/cons of token storage.

Just wondered if there were any thoughts on this?

[judedaryl]

Best practice i guess would be to use transient memory to store the tokens. Then you could just use silent token request to validate if a user is logged in or not. It does add some overhead to the whole flow especially when the user is just refreshing,

[yogilad]

Hi @jasonnutter ,
A customer of ours has ordered an external audit of our SPA, and this issue was reported back as a vulnerability.
Is there an update on intention to fix this issue and any expected ETA for release?

[jasonnutter]

@yogilad There is a PR up for user-provided storage in MSAL.js v2. It should be available in an upcoming release, but we don't have an expected ETA at this time.

[yogilad]

Thanks!
We'll keep an eye on future releases.

[izikl]

@jasonnutter will it be available for msal library as well or just for msal-browser?

In msal-browser what is being persisted in local storage - the auth code, the access-token or both?

[jasonnutter]

@jasonnutter will it be available for msal library as well or just for msal-browser?

@izikl Only for @azure/msal-browser.

In msal-browser what is being persisted in local storage - the auth code, the access-token or both?

The access tokens, id tokens, and refresh tokens are cached in local/session storage. The auth code is only stored in memory.

[jasonnutter]

"memoryStorage" is now available in the latest version of MSAL Browser v2. Closing.