MSAL.js与Axios并行请求时acquireTokenPopup交互冲突问题

我们通过Axios请求拦截器从MSAL.js获取访问令牌，并将其以Bearer令牌形式添加到所有后端API请求中，代码如下：

const acquireToken = async () => {
  const accounts = msalInstance.getAllAccounts();

  if (accounts.length === 0) return null;

  const request = {
    scopes: process.env.scopes || [],
    account: accounts[0],
  };

  try {
    return await msalInstance.acquireTokenSilent(request);
  } catch (error) {
    if (error instanceof InteractionRequiredAuthError) {
      return await msalInstance.acquireTokenPopup(request);
    }

    return null;
  }
}

const getAccessToken = async () => {
  const token = await acquireToken();
  return token?.accessToken || '';
}

axiosInstance.interceptors.request.use(
  async (config) => {
    const configured = config;
    const token = await getAccessToken();
    configured.headers.Authorization = `Bearer ${token}`;
    return configured;
  },
  (error: any) => Promise.reject(error)
);

当用户打开应用内某路由时，会同时发送多个并行请求，示例代码：

useEffect(() => {
  Promise.all([getMovies(), getActors()]).then(([_movies, _actors]) => {
    // ...
  });
}, []);

我们希望保持请求并行以保证效率，但当前存在问题：当令牌过期需要交互式登录时，所有并行请求都会调用acquireTokenPopup，最终只有一个请求成功，其余均抛出interaction_in_progress错误。

现有疑问：

1. MSAL文档提到acquireTokenSilent在并行请求时会返回当前正在处理的Promise，为什么acquireTokenPopup不支持这种机制？
2. 该场景下的最佳处理方式是什么？
3. 是否有库可以封装MSAL调用，实现并行请求时仅触发一次令牌获取调用？
4. 在Axios拦截器中调用MSAL是否并非合理方案？

1. 为什么acquireTokenPopup不支持复用Promise？ #

acquireTokenSilent是纯后台操作，MSAL内部通过缓存和状态跟踪实现了并行请求的Promise复用，避免重复刷新令牌。而acquireTokenPopup涉及交互式用户操作（弹出登录窗口），这类操作本身无法并行执行——浏览器会限制同时弹出多个窗口，且用户也不可能同时完成多次登录交互。MSAL设计时没有为这类交互式方法做Promise复用，因为从交互逻辑和用户体验角度，多次并行触发毫无意义，反而会造成混乱。

2. 最佳处理方式：手动实现令牌获取的请求防抖/复用 #

核心思路是在getAccessToken层维护一个全局的令牌获取Promise，当已有请求在获取令牌（尤其是交互式获取）时，后续请求直接复用这个Promise，避免重复调用。

修改后的代码示例：

// 维护一个全局Promise，用于复用正在进行的令牌请求
let tokenPromise = null;

const acquireToken = async () => {
  const accounts = msalInstance.getAllAccounts();
  if (accounts.length === 0) return null;

  const request = {
    scopes: process.env.scopes || [],
    account: accounts[0],
  };

  try {
    return await msalInstance.acquireTokenSilent(request);
  } catch (error) {
    if (error instanceof InteractionRequiredAuthError) {
      return await msalInstance.acquireTokenPopup(request);
    }
    return null;
  }
}

const getAccessToken = async () => {
  // 如果已有令牌请求在进行，直接复用Promise
  if (tokenPromise) {
    const token = await tokenPromise;
    return token?.accessToken || '';
  }

  // 否则发起新的请求，并将Promise缓存
  tokenPromise = acquireToken();
  try {
    const token = await tokenPromise;
    return token?.accessToken || '';
  } finally {
    // 请求完成后清空缓存，避免后续请求复用过期的Promise
    tokenPromise = null;
  }
}

// Axios拦截器代码保持不变
axiosInstance.interceptors.request.use(
  async (config) => {
    const configured = config;
    const token = await getAccessToken();
    configured.headers.Authorization = `Bearer ${token}`;
    return configured;
  },
  (error: any) => Promise.reject(error)
);

这个方案能确保无论多少并行请求，同一时间只会有一个令牌获取操作（包括交互式的acquireTokenPopup），所有请求等待同一个Promise结果，从根源避免interaction_in_progress错误。

3. 有没有现成的封装库？ #

目前没有专门针对这个场景的轻量库，因为上述逻辑实现简单，大部分项目都是手动添加这个Promise复用层。如果使用MSAL React（@azure/msal-react），可以利用其提供的useMsal钩子和useAccessToken封装，内部已经处理了类似的请求防抖逻辑，不过本质也是基于全局状态跟踪实现的。

4. Axios拦截器中调用MSAL是否合理？ #

这是非常常见且合理的方案，拦截器是统一处理请求头的最佳位置，能避免在每个API调用中重复编写令牌添加逻辑。只要解决了并行请求的令牌获取冲突问题，这个方案就可以稳定运行。

需要注意的是：

• 确保拦截器中的异步逻辑不会导致请求阻塞过长时间（比如交互式登录时，用户可能需要几秒到几十秒完成操作）
• 可以添加超时处理，避免因用户未完成登录导致请求永久挂起

内容的提问来源于stack exchange，提问作者andkorsh