Angular MSAL疑问：Bearer令牌、AUD属性配置及API 401问题

我正在配置MSAL库实现Azure AD登录，采用APP_INIT中的重定向流，已成功登录并获取令牌。使用的配置如下：

export function MSALInstanceFactory(): IPublicClientApplication {
  return new PublicClientApplication({
    auth: {
      clientId: '4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
      authority: 'https://login.microsoftonline.com/2716828a-xxxx-xxxx-xxxx-xxxxxxxxxxxx',
      protocolMode: ProtocolMode.OIDC,
      redirectUri: '/',
      postLogoutRedirectUri: '/'
    },
    cache: {
      cacheLocation: BrowserCacheLocation.LocalStorage,
      storeAuthStateInCookie: false
    },
    system: {
      // ... just logging
    }
  });
}

export function MSALInterceptorConfigFactory(): MsalInterceptorConfiguration {
  const protectedResourceMap = new Map<string, Array<string>>();
  protectedResourceMap.set('/', ['api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test']);

  return {
    interactionType: InteractionType.Redirect,
    protectedResourceMap
  };
}

目前用户访问页面会自动跳转至Azure登录页，认证完成后返回，Bearer令牌已附加到user/getInfo端点，但该令牌为不可解析的opaque字符串。查看ID token的AUD属性值为配置中的clientId：

aud: '4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx'

本地存储中存在目标WEB API资源记录：

target: "api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test"

后端开发人员指出Bearer应为可解析的标准JWT，且我们均对AUD属性存疑：它是否应等于WEB API的clientId？当前Rest API返回401错误，无法确定是前端配置问题还是后端问题，请问我的配置是否正确？

你的配置存在关键问题，同时存在对令牌类型的理解误区，具体如下：

1. protectedResourceMap 配置错误 #

你将根路径/映射到API权限范围，这会导致MSAL拦截器对所有请求尝试获取令牌，但路径匹配过于宽泛，无法精准触发针对目标API的Access Token请求，进而返回了不可解析的opaque令牌。

修正方式：将映射路径改为API的实际端点前缀（比如/user，对应user/getInfo接口），确保拦截器只针对API请求获取正确的令牌：

const protectedResourceMap = new Map<string, Array<string>>();
// 匹配/user开头的所有请求，获取对应API的令牌
protectedResourceMap.set('/user', ['api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test']);

2. AUD 属性的正确理解 #

• ID Token的aud：确实等于前端应用的ClientId（4015ef49-xxxx-xxxx-xxxx-xxxxxxxxxxxx），这是正常行为——ID Token用于验证前端用户身份，受众是前端应用本身，和后端API无关。
• 后端需要的是Access Token：Access Token的aud才应该等于API的ClientId（15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx），这是后端验证令牌有效性的核心依据。你当前可能误将ID Token作为Bearer令牌发送给了后端，或者没有获取到正确的Access Token。

3. Opaque令牌的排查方向 #

出现opaque令牌通常是因为MSAL未正确请求到目标API的Access Token，需额外检查：

• 前端应用在Azure AD中已被授予该API的权限（需在Azure Portal配置API权限并完成管理员同意）；
• 确认API的权限范围api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test在Azure AD中已正确定义。

4. 快速验证方法 #

手动调用acquireTokenSilent获取针对API的令牌，检查返回结果：

const request = {
  scopes: ['api://15c38238-xxxx-xxxx-xxxx-xxxxxxxxxxxx/api.test']
};
msalInstance.acquireTokenSilent(request).then(response => {
  console.log(response.accessToken); // 应为可解析的JWT
  console.log(jwtDecode(response.accessToken).aud); // 应等于API的ClientId
});

如果返回的是正确的JWT且aud符合预期，说明前端配置修正后即可解决问题；若仍有问题，需排查后端的令牌验证逻辑是否正确识别Access Token的aud。

内容的提问来源于stack exchange，提问作者mat.hudak