MSAL 刷新令牌过期后出现重复登录，如何排查和处理？

建议先调整 ErrorComponent，不要在错误组件挂载时无条件调用 loginRedirect()。页面已经使用 MsalAuthenticationTemplate 管理认证，再增加一个自动登录入口，可能导致失败后立即重试、重复跳转或交互冲突。

现有代码还不足以确认根因是刷新令牌过期。材料中缺少实际错误码、重定向记录和完整的初始化代码，应先区分“应用发起了两次认证请求”和“同一次认证过程中要求用户再次输入凭据”。

先移除错误组件中的自动登录

原来的错误组件不判断错误类型，只要挂载就发起登录。配置错误、网络异常和需要用户交互的错误都会走同一条路径，而且没有处理 loginRedirect() 失败的情况。

可以先让错误组件只显示错误，使认证失败后停下来，以便观察原因：

import React from 'react';

type ErrorProps = {
  error?: {
    errorCode?: string;
    message?: string;
  };
};

export const ErrorComponent = ({ error }: ErrorProps): JSX.Element => (
  <div role="alert">
    <p>身份认证未完成，请稍后重试。</p>
    {error?.errorCode && <code>{error.errorCode}</code>}
  </div>
);

移除这个重复发起登录的入口后，可能存在的其他令牌问题仍需排查。需要重试时，应通过统一入口触发，同时处理正在进行的交互和重试失败。

将页面登录与 API 令牌获取分开处理

MsalAuthenticationTemplate 用于控制认证后的页面访问。用户已经登录，并不意味着某个 API 所需的 access token 一定能静默取得。

可以分成两条路径处理：

• 页面没有可用账户时，由页面认证入口处理登录。
• 页面调用 API 时，先执行 acquireTokenSilent()；只有需要用户交互的失败，才进入统一的交互式回退。

不要把所有异常都转换成 loginRedirect()。网络故障或请求配置错误通常需要修复对应问题，反复登录未必有用。

下面的示例将静默取令牌的结果交给调用方处理，底层函数不自行触发导航：

import {
  AuthenticationResult,
  InteractionRequiredAuthError,
  IPublicClientApplication,
  SilentRequest,
} from '@azure/msal-browser';

type TokenOutcome =
  | { kind: 'success'; result: AuthenticationResult }
  | { kind: 'interaction-required'; request: SilentRequest };

export async function acquireApiToken(
  instance: IPublicClientApplication,
  request: SilentRequest,
): Promise<TokenOutcome> {
  try {
    const result = await instance.acquireTokenSilent(request);
    return { kind: 'success', result };
  } catch (error) {
    if (error instanceof InteractionRequiredAuthError) {
      return { kind: 'interaction-required', request };
    }

    throw error;
  }
}

调用方收到 interaction-required 后，可以显示“继续认证”按钮，或交给应用统一的认证控制逻辑处理。交互式取令牌可以使用 acquireTokenRedirect()，并保持所需的 scopes、authority、账户及必要业务参数一致。

在 React 中，可以通过 useMsal() 返回的 inProgress 判断当前是否为 InteractionStatus.None，没有其他交互进行时再考虑启动下一次交互。如果多个 API 请求同时失败，还需要共享的协调逻辑，避免每个请求分别发起重定向；单个组件里的局部标记无法覆盖其他入口。

检查重定向返回后的账户状态

原函数在 getActiveAccount() 返回空值时会抛错。这个错误本身不能证明登录会话或刷新令牌已经失效，也可能是应用没有正确设置 active account。

需要检查以下几点：

1. MsalProvider 与业务函数是否使用同一个 MSAL 实例。
2. 登录重定向返回后，认证结果是否已经处理完成，业务组件是否过早开始取令牌。
3. 登录成功后是否按应用的账户选择规则调用了 setActiveAccount()。
4. 页面刷新后，缓存中有账户但 active account 为空时，应用如何恢复账户选择。

只有一个缓存账户时，可以按应用规则选用该账户；存在多个账户时，应明确用户要使用哪一个，不宜直接取数组第一项。

使用 MsalProvider 时，还应核对现有的重定向处理安排，避免在多个组件里重复处理回调。材料没有提供 _app 中的初始化实现，因此无法判断这一环节是否正确。

核对 /blank 与交互式回调地址

原代码给静默请求指定了 /blank，但没有展示该页面的内容，也没有展示 MSAL 的全局 redirectUri。

需要核对：

• 实际使用的回调地址是否已在 Azure App Registration 中按对应平台配置。
• /blank 是否能直接访问，是否被中间件、路由守卫或认证模板再次重定向。
• 用于静默认证的页面是否执行了额外的登录逻辑。
• 交互式回调返回后，应用是否能够完成响应处理并恢复业务流程。

静默请求和交互式请求可以使用不同的回调页面，但每个页面都必须符合各自用途。不能只凭路径名判断 /blank 的配置是否正确。

此外，材料没有给出 loginRequest、loginRequestCap 和 dnsUrl 的具体内容。应记录脱敏后的实际 scopes、authority、redirect URI 及相关参数，确认失败前后使用的是否为预期配置。

修正返回类型和令牌用途

原函数声明为 Promise<void>，实际却返回认证结果、令牌字符串或其他字段。应根据真实返回值定义类型。为便于维护，可以先返回 AuthenticationResult，再由调用方读取需要的字段。

需要删除这段回退：

msIdTokenResponse = response?.accessToken || response?.idToken;

调用受保护 API 时，应使用面向该 API 的 access token。ID token 用于身份认证，不能因为 access token 为空就拿来替代。

如果调用方需要 API 令牌，应明确检查结果：

const outcome = await acquireApiToken(msalInstance, request);

if (outcome.kind === 'success') {
  const accessToken = outcome.result.accessToken;

  if (!accessToken) {
    throw new Error('No access token returned for the requested API.');
  }

  // Use accessToken when calling the intended API.
}

// Handle interaction-required through the shared authentication flow.

示例中的 request 需要使用应用实际的账户、scopes 和认证配置构造，不能直接使用脱敏占位符。

用日志确认重复登录发生在哪一层

下一次复现时，可以围绕一次操作记录以下信息，无需输出任何令牌：

保留浏览器网络日志时，应遮蔽 Cookie、Authorization header、授权码及令牌。再通过锁文件或包管理器输出确认实际安装版本。^2.23.0 和 ^1.3.2 是依赖范围，不能据此断言运行的是哪个补丁版本，也不能直接认定某个版本存在缺陷。

如果日志最终显示静默取令牌确实需要用户交互，应用应进入一次受控的交互式认证。是否需要重新输入密码，还取决于当时的登录会话和身份验证要求，现有材料不足以保证全程无提示。

备注：内容仅供参考。