User Token Issue preferred_username msal-browser and msal-react

[rameshlamaniweir]

Core Library

MSAL.js (@azure/msal-browser)

Core Library Version

5.0.2

Wrapper Library

MSAL React (@azure/msal-react)

Wrapper Library Version

5.0.2

Public or Confidential Client?

Public

Description

User Type 1: When a user logs in using their email and password or the number from the authenticator popup, the process functions smoothly without any issues. In this scenario, multiple different users can log in and out repeatedly, and tokens are generated for the corresponding users, without any empty cache, hard refersh etc.

User Type 2: When a user logs in using their email and number from the authenticator popup, the process functions smoothly without any issues. In this scenario, multiple different users can log in and out repeatedly, and tokens are generated for the corresponding users, without any empty cache, hard refersh etc.

User Type 3: The problem arises when a user logs in using their email and the code generated for account verification in Outlook (one time OTP code). In such cases, the tokens become mixed up with those of the previous user. If we do the empty cache, hard refresh same issue is exist. But when we close the browser and open new incognito window it works fine.

When we log in using the email and password of User 1, and subsequently log out to log in again with the email of User Type 2 and a one-time code (OTP) from Outlook, the session is taken from the previous mixed-up token. Upon decoding the token, all data appears to be correct; however, the preferred_username will still reflect the previous user.

Error Message

There is no error message; instead, we are indicating that incorrect data is present in the application due to the issue with the mixed token.

{
"aud": "correct data",
"iss": "correct data"",
"iat": correct data",
"nbf": correct data",
"exp": correct data",
"aio": "correct data"",
"azp": "correct data"",
"azpacr": "0",
"idp": "mail",
"name": "correct data"",
"oid": "correct data"",
"preferred_username": "seeing here Wrong previous user email id will display",
"rh": "correct data"",
"scp": "correct data"",
"sid": "correct data"",
"sub": "correct data"",
"tid": "correct data"",
"uti": "correct data",
"ver": "correct data"",
"xms_ftd": "correct data""
}

MSAL Logs

No response

Network Trace (Preferrably Fiddler)

• Sent
• Pending

MSAL Configuration

export const msalConfig: Configuration = {
  auth: {
    clientId: `${process.env.NEXT_PUBLIC_CLIENT_ID}`,
    authority: `${process.env.NEXT_PUBLIC_AUTHORITY_BASE_URL}${process.env.NEXT_PUBLIC_TENANT_ID}`,
    redirectUri: `${process.env.NEXT_PUBLIC_REDIRECT_URL}`,
    postLogoutRedirectUri: `${process.env.NEXT_PUBLIC_REDIRECT_URL}`,
  },
  cache: {
    cacheLocation: 'sessionStorage',
  },
  system: {
    allowPlatformBroker: false, // Disables WAM Broker
  },
};

Relevant Code Snippets

import { MsalProvider } from '@azure/msal-react';
import {
  PublicClientApplication,
  AuthenticationResult,
  EventType,
} from '@azure/msal-browser';

// Create MSAL instance only on client side to avoid SSR issues
let msalInstance: PublicClientApplication | null = null;

async function initializeMsalAsync(
  router: ReturnType<typeof useRouter>
): Promise<PublicClientApplication | null> {
  if (globalThis.window === undefined) return null;
  msalInstance ??= new PublicClientApplication(msalConfig);
  const navigationClient = new CustomNavigationClient(router);
  msalInstance.setNavigationClient(navigationClient);

  // MSAL v5: must await initialize() before using; handleRedirectPromise() processes post-login redirect
  await msalInstance.initialize();
  const redirectResponse = await msalInstance.handleRedirectPromise();
  if (redirectResponse?.account) {
    msalInstance.setActiveAccount(redirectResponse.account);
  } else {
    const accounts = msalInstance.getAllAccounts();
    if (accounts.length > 0) {
      msalInstance.setActiveAccount(accounts[0]);
    }
  }

  // console.log('Accounts:', msalInstance.getAllAccounts());
  // console.log('Active:', msalInstance.getActiveAccount());

  msalInstance.addEventCallback((event) => {
    if (
      event.eventType === EventType.LOGIN_SUCCESS &&
      (event.payload as AuthenticationResult)?.account
    ) {
      const account = (event.payload as AuthenticationResult).account;
      msalInstance!.setActiveAccount(account);
    }
  });

  return msalInstance;
}

Reproduction Steps

log in using the email and password of User 1, and subsequently log out to log in again with the email of User Type 2 and a one-time code (OTP) from Outlook, the session is taken from the previous mixed-up token. Upon decoding the token, all data appears to be correct; however, the preferred_username will still reflect the previous use

Expected Behavior

Regardless of the type of user, the system should generate the correct token even during multiple logins and logouts with different users. This applies whether the login is conducted through email, password, popup code, or a one-time password sent to their Outlook email.

Identity Provider

Entra ID (formerly Azure AD) / MSA

Browsers Affected (Select all that apply)

Chrome

Regression

No response