User Token Issue preferred_username msal-browser and msal-react

Question

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 Configuration

export

Relevant Code Snippets

import

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, Edge and other browsers

Answer 1

The issue you're experiencing with mixed tokens when using one-time passwords (OTP) for login could be related to how MSAL.js handles session management and token caching. Here are some points to consider:

1. Session Management: MSAL.js relies on session cookies set in the browser. If multiple users log in and out in the same browser session, the session state may not be cleared properly, leading to token mixing. This is especially true if the application does not handle logout correctly or if the session is not fully terminated before a new login.
2. Token Caching: When using MSAL, tokens are cached in the browser. If the cache is not cleared properly during logout, it may still hold onto the previous user's tokens, which can lead to the issue you're seeing with the preferred_username reflecting the previous user.
3. Using ssoSilent Method: If your application is using the ssoSilent method for silent token acquisition, ensure that you are passing the correct parameters (like login_hint or account) to avoid ambiguity when multiple accounts are present in the session. This can help in correctly identifying the user for whom the token is being requested.
4. Incognito Mode: The fact that the issue does not occur in an incognito window suggests that the problem is related to session persistence in the standard browsing mode. Incognito mode does not retain session cookies or cache between sessions, which is why it works correctly there.
5. Logout Implementation: Ensure that your logout implementation is correctly clearing the session and tokens. You may want to explicitly call the logout method provided by MSAL to clear the session state.
6. Testing Across Browsers: Since you mentioned multiple browsers, ensure that the behavior is consistent across them. Sometimes, browser-specific caching or session handling can lead to different behaviors.

To resolve this issue, consider implementing a more robust logout process that clears the session and cache, and ensure that you are using the correct parameters when acquiring tokens for different users. You may also want to review the MSAL documentation for best practices on managing sessions and tokens effectively.

---

References:

• Single sign-on with MSAL.js
• Accounts in MSAL Browser