Microsoft-authentication-library-for-js: Password reset flow not working due to cache not cleared

[Calamari]

Library

• [ ] [email protected] or @azure/[email protected]
• [x] @azure/[email protected]
• [ ] @azure/[email protected]
• [ ] @azure/[email protected]
• [ ] @azure/[email protected]
• [ ] @azure/[email protected]
• [ ] @azure/[email protected]
• [ ] @azure/[email protected]

Framework

none

Description

We are currently switching from MSAL 1 to MSAL 2 since it is now handling b2c correctly and have a problem with out password flow. What is happening is, that we send the user off to the login page, where he clicks the "forget password" link, which leads him back to our page with the error code "AADB2C90118", we take this as clue and try log him in again, but this time using a passwordResetAuthority. This did lead the user to the expected form to reset his password before (with [email protected]) but with new [email protected] it does not work, because it just errors out with interaction_in_progress.

Error Message

The error we get it’s errorCode is interaction_in_progress.

Regression

• [x] Did this behavior work before?
  Version: In [email protected] it worked

MSAL Configuration

This is basically all the code we use on the login page (stripped out of its classes for clarity):

const msalSettings = {
  auth: {
    knownAuthorities: settings.knownAuthorities,
    authority: settings.signInAuthority,
    clientId: settings.clientId,
    postLogoutRedirectUri: window.location.origin,
    redirectUri: `${window.location.origin}/login`,
    navigateToLoginRequestUrl: false
  },
  cache: {
    cacheLocation: "localStorage",
    storeAuthStateInCookie: false
  }
};

const errorMatch = window.location.hash.match(regexError);
if (errorMatch) {
  const errorDescription = decodeURIComponent(errorMatch[2]);
  const exception = new Error(`${errorMatch[1]}: ${errorDescription}`);
  const errorCode = errorDescription.split(":")[0];
  if (errorCode === "AADB2C90118") {
    doPasswordReset();
  } else {
    throw exception;
  }
} else {
  login();
}


function doPasswordReset() {
  msalSettings.auth.authority = settings.passwordResetAuthority;
  msalSettings.auth.redirectUri = `${window.location.origin}/callback`;
  const msal = new Msal.PublicClientApplication(msalSettings);
}

function login() {
  const msal = new Msal.PublicClientApplication(msalSettings);
  msal.loginRedirect({ scopes: settings.scopes });
}

Note about a workaround, that we definitely do not want to do:

If we started the doPasswordReset method with this little addition, it would work as expected and leads to the proper page:

function doPasswordReset() {
  window.localStorage.clear();
  //  … rest the same
}

But as you can understand, clearing the whole localStorage is not a viable solution. But it fixes the problem that somehow there is some part of the cache from the signInAuthority bleeding over (or just not cleared) to the passwordResetAuthority.

Expected behavior

Well it should lead

Browsers/Environment

• [x] Chrome
• [x] Firefox
• [ ] Edge
• [ ] Safari
• [ ] IE
• [ ] Other (Please add browser name here)

Maybe we are doing something utterly wrong (and did so in the past) but it worked before so, please help :-)

[tnorling]

@Calamari Msal clears the interaction status when it processes the response from the server. Since you are handling the response yourself this is why the cache entry is not being cleared. What you should do instead is:

1. Call loginRedirect
2. If the user clicks reset password they will be redirected back to the app with an error
3. Call handleRedirectPromise and catch the error
4. If the error is the password reset error call loginRedirect({authority: password_reset_authority})

You can find an example of this flow here

[derisen]

@Calamari likewise, you can find an msal.js 2.x B2C sample with password reset flow here.

[Calamari]

Ha, thank you, @tnorling & @derisen.

We did indeed call handleRedirectPromise(), but only in the login case (so we don't find an error). I forgot to visualize that in my code extract above. But it looks like to use that in all cases was the pointer that I needed. Now, it works and seem to clear up all the cache.

Sometimes you just need some fresh pair of eyes to point to you doing something stupid if you have tomatoes on your eyes :-) (Not quite sure if that phrase translates well to English though.)

Thanks again, I will close this now, since there was never a real problem (except my understanding).