Angular集成MSAL 新标签页打开链接需重复登录问题

你配置cacheLocation不生效的核心原因是配置层级写错了。MSAL 不会识别嵌套在azure/auth节点下的cache配置，读不到自定义配置就会默认回退到sessionStorage存储，这才是你改了参数还是存在会话存储里的根本原因，和MSAL所谓的"默认强制用sessionStorage"的说法没关系。

• 调整MSAL初始化配置结构，把cache节点和auth节点平级放置，参考如下代码：

// 应用初始化时的MSAL实例配置
export function MSALInstanceFactory(): IPublicClientApplication {
  return new PublicClientApplication({
    auth: {
      clientId: '你的clientID',
      authority: '你的authority地址',
      redirectUri: 'http://localhost:4200'
    },
    // 注意：cache和auth是平级属性，不要嵌套在auth对象内部
    cache: {
      cacheLocation: 'localStorage',
      storeAuthStateInCookie: false // 仅需要兼容IE/老旧Edge版本时开启，现代浏览器保持关闭即可
    }
  });
}

• 你现有路由里加MsalGuard的写法没有问题，配置生效后Guard会自动从localStorage读取登录态，不需要额外修改路由逻辑。
• 配置修改完成后，清空浏览器里当前域名下的所有sessionStorage、localStorage缓存，重启应用再验证，避免旧缓存干扰结果。

• 这是MSAL官方明确支持的存储方案，不存在不符合设计规范的问题，同域下多标签页共享登录态是这个配置的标准使用场景
• 配置生效后，新标签页粘贴同域链接打开时，MSAL会直接读取localStorage里的已登录账号信息，自动通过MsalGuard校验，不会再跳转到登录页要求手动选择账号
• 如果碰到极个别多标签页状态不同步的情况，可以在应用根组件初始化时主动执行一次this.msalService.instance.getAllAccounts()，触发缓存主动加载即可。

• 如果你用的是@azure/msal-angular v1版本，cacheLocation确实是放在auth节点下的，v2及以上版本才调整为平级的cache节点，注意对应你安装的包版本调整结构
• 不要同时混用sessionStorage和localStorage配置，同一应用下保持统一的缓存位置配置，避免出现token读取异常

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