Azure AD B2C keeps providing v1 tokens not v2 tokens

Azure's AD B2C keeps issuing v1 tokens even though v2 tokens are configured in the manifest of the SPA app that's registered:

{
    "id": "XXX",
    "acceptMappedClaims": null,
    "accessTokenAcceptedVersion": 2,
    "addIns": [],
    "allowPublicClient": null,
    ...
}

The client uses @azure/msal-angular v2.0.5 (along with @azure/msal-browser v2.19.0) to request the token via a plain MSAL Interceptor:

export const protectedResourceMap: Map<string, Array<string>> = new Map([
  [
    urlJoin(configs.apiUri, 'screen'),
    [configs.authConfig.scope.screen_access],
  ],
]);

@NgModule({
  imports: [
    MsalModule.forRoot(
      new PublicClientApplication({
        auth: {
          clientId: '...',
          authority: 'https://login.microsoftonline.com/XXX.onmicrosoft.com',
          postLogoutRedirectUri: '.../logout',
          navigateToLoginRequestUrl: true,
          redirectUri: '.../auth',
        },
        cache: {
          cacheLocation: 'sessionStorage',
        },
      }),
      {
        interactionType: InteractionType.Redirect, // Popup or Redirect
        loginFailedRoute: '/login-failed'
      },
      {
        interactionType: InteractionType.Redirect,  // Popup or Redirect
        protectedResourceMap,
      })
      ...

This seems to look OK, especially the "accessTokenAcceptedVersion": 2.

What might be the root cause of the token still being of v1?

{
  "aud": "00000003-XXXX-XXXX-XXXX-XXXXXXXXXXXX",
  "iss": "https://sts.windows.net/7dcXX-XXXXX.../",
  ...
  "ver": "1.0",
  ...
}

Pointers would be much appreciated.

Solution

Azure AD B2C only ever used the endpoint when making the OIDC Authentication requests with v2.0, a v1.0 never existed. So it always has issued v1.0 tokens (v2 is the first and only version). This is completely normal.

Only Azure AD had v1.0 and v2.0 OIDC endpoint, and therefore maps based off of accessTokenAcceptedVersion.

You don't need to mess with this property in AAD B2C application registrations unless you have a SAML relying party.