Skip to content

[v5] Changes to Configuration - CacheOptions (Config #2) #7697

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 14 commits into
base: msal-v5
Choose a base branch
from

Conversation

jo-arroyo
Copy link
Collaborator

@jo-arroyo jo-arroyo commented Apr 12, 2025

This PR updates the CacheOptions for MSAL Browser v5, including:

  • Deprecates temporaryCacheLocation and claimsBasedCachingEnabled
  • Removal of implementation, tests, and doc references for storeAuthStateInCookie, secureCookies, and cacheMigrationEnabled

@github-actions github-actions bot added documentation Related to documentation. msal-angular Related to @azure/msal-angular package samples Related to the samples apps for the library. msal-browser Related to msal-browser package labels Apr 12, 2025
@@ -171,10 +171,9 @@ export function redirectPreflightCheck(
): void {
preflightCheck(initialized);
blockRedirectInIframe(config.system.allowRedirectInIframe);
// Block redirects if memory storage is enabled but storeAuthStateInCookie is not
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we still want to block redirects with memory storage here?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes. On redirect, in memory cache is reset and the authentication will forever loop since there is no cache state indicating a previous redirect request is in progress on reload. This check prevents users ever attempting redirect since we cannot support it.

@github-actions github-actions bot added the msal-common Related to msal-common package label Apr 12, 2025
@jo-arroyo jo-arroyo changed the title [v5] Changes to Configuration - CacheOptions [v5] Changes to Configuration - CacheOptions (Config #2) Apr 14, 2025
@jo-arroyo jo-arroyo marked this pull request as ready for review April 14, 2025 17:03
Copy link
Contributor

@shylasummers shylasummers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM but somebody else should weigh in on whether to block redirects with memory storage

@@ -71,6 +71,9 @@ To faciliate efficient token acquisition while maintaining a good UX, MSAL cache
> :bulb: The authorization code is only stored in memory and will be discarded after redeeming it for tokens.

## Warning :warning:

**NOTE: `temporaryCacheLocation` is deprecated as of MSAL v5 and will be removed in a future release.**

Overriding `temporaryCacheLocation` should be done with caution. Specifically when choosing `localStorage`. Interaction in more than one tab/window will not be supported and you may receive `interaction_in_progress` errors unexpectedly. This is an escape hatch, not a fully supported feature.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We are keeping the docs? I assumed if it is removed, wouldn't it be just removal notice in migration guidance since this branch is V5?

| `storeAuthStateInCookie` | If true, stores cache items in cookies as well as browser cache. Should be set to true for use cases using IE. | boolean | `false` |
| `secureCookies` | If true and `storeAuthStateInCookies` is also enabled, MSAL adds the `Secure` flag to the browser cookie so it can only be sent over HTTPS. | boolean | `false` |
| `cacheMigrationEnabled` | If true, cache entries from older versions of MSAL will be updated to conform to the latest cache schema on startup. If your application has not been recently updated to a new version of MSAL.js you can safely turn this off. In the event old cache entries are not migrated it may result in a cache miss when attempting to retrieve accounts or tokens and affected users may need to re-authenticate to get up to date. | boolean | `true` when using `localStorage`, `false` otherwise |
| `claimsBasedCachingEnabled` | If `true`, access tokens will be cached under a key containing the hash of the requested claims string, resulting in a cache miss and new network token request when the same token request is made with different or missing claims. If set to `false`, tokens will be cached without claims, but all requests containing claims will go to the network and overwrite any previously cached token with the same scopes. | boolean | `false` |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Let us ensure we test this, that we never cache claims. I want to make sure we have Loop who had this bug before, and Teams who I think are setting this to false are not broken with v5.

@@ -95,11 +93,8 @@ const msalInstance = new PublicClientApplication(msalConfig);
| Option | Description | Format | Default Value |
| --------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------- | --------------------------------------------------- |
| `cacheLocation` | Location of token cache in browser. | String value that must be one of the following: `"sessionStorage"`, `"localStorage"`, `"memoryStorage"` | `sessionStorage` |
| `temporaryCacheLocation` | Location of temporary cache in browser. This option should only be changed for specific edge cases. Please refer to [caching](https://github.com/AzureAD/microsoft-authentication-library-for-js/blob/dev/lib/msal-browser/docs/caching.md#cached-artifacts) for more. | String value that must be one of the following: `"sessionStorage"`, `"localStorage"`, `"memoryStorage"` | `sessionStorage` |
| `storeAuthStateInCookie` | If true, stores cache items in cookies as well as browser cache. Should be set to true for use cases using IE. | boolean | `false` |
| `secureCookies` | If true and `storeAuthStateInCookies` is also enabled, MSAL adds the `Secure` flag to the browser cookie so it can only be sent over HTTPS. | boolean | `false` |
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Off the topic, but related. Can we make sure the one cookie we set for KMSI is the only one we manage and add it to the docs under cookies MSAL JS manages.. etc. Also link to the migration guide on the discontinuation of existing cookies.

Copy link
Member

@sameerag sameerag left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we make sure we have tests for claimbased caching and inmemory storage blocking redirects? There could be existing ones, just make sure they are comprehensive.

Approving.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Related to documentation. msal-angular Related to @azure/msal-angular package msal-browser Related to msal-browser package msal-common Related to msal-common package samples Related to the samples apps for the library.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants