microsoft-authentication-library-for-js: idTokenClaims undefined for Angular 17

Core Library

MSAL.js (@azure/msal-browser)

Core Library Version

3.0.8

Wrapper Library

MSAL Angular (@azure/msal-angular)

Wrapper Library Version

3.5.0

Public or Confidential Client?

Public

Description

After updating Angular from version 16 to 17, I’m encountering an issue. Although I can successfully log in and retrieve the account using MsalService.instance.getActiveAccount(), the idTokenClaims property is coming back as undefined. This is preventing access to the user’s name and their claims/permissions.

Interestingly, this issue is specific to Angular 17, as it was not present in Angular 16.

Error Message

No response

Msal Logs

No response

MSAL Configuration

{
  auth: {
    clientId: 'XXXXXX',
    authority: 'XXXXXX',
    knownAuthorities: ['XXXXXX', 'XXXXXX'
    ],
    redirectUri: '/', 
  },
  cache: {
    cacheLocation: BrowserCacheLocation.LocalStorage, 
  },
}

Relevant Code Snippets

import { MsalService } from '@azure/msal-angular';

// component rendered after successful login
constructor(
    private authService: MsalService,
  ) {
    const account = this.authService.instance.getActiveAccount();
    const claims = account.idTokenClaims;
    console.log("Account: ", account, " , claims: ", claims); // claims is undefined
}

Reproduction Steps

Update an Angular application from version 16 to 17.
Implement authentication using @azure/msal-angular and @azure/msal-browser.
Login, end the currenct session (close tab or browser), revisit the site and attempt to access idTokenClaims while stil logged in.

Expected Behavior

The idTokenClaims property should provide access to the user’s ID token claims, including their username and permissions.

Identity Provider

Azure B2C Custom Policy

Browsers Affected (Select all that apply)

Chrome

Regression

No response

Source

Internal (Microsoft)

About this issue

Original URL
State: closed
Created 8 months ago
Comments: 21 (6 by maintainers)

Most upvoted comments

Also getting the same symptoms with msal-browser 3.5.0 (Using it with Vue). It did worked well with msal-browser 3.1.0

Allright, after some debugging, I found the root cause (for my case, but maybe it can help for other people who have the same issue) It was because the environment property of my idtoken did not match any of the knownauthorities of the auth config (the config object passed when initializing the msal instance)

Details: The method CacheManager.getIdToken() wasn’t able to return the IdToken from the browser cache. It was successfully able to retrieve all idtokens from the cache (which in my case, there was only one) but failed to validate it against my config. It tries to match it against the clientId, homeAccountId, environment and so on. In my case, it didn’t match on the environment <-> knownauthorities because I had used the same value for ‘knownauthorities’ than for ‘authority’ and it was slighly different (I’m using ADFS)

NikoGJ on Nov 20, 2023

@hectormmg I’ll get you a trace log tomorrow, thank you for looking into this. Re-authenticating does not fix the issue for me. Also one more thing - everything works fine on the first pageload after signing in, but when I refresh the page or try to navigate to another route the issue occurs and from what I can see by consolelogging the account the only difference is that idTokenClaims is undefined and the idToken-property is completely missing.

jingfee on Nov 14, 2023

Also getting the same symptoms with msal-browser 3.5.0 (Using it with Vue). It did worked well with msal-browser 3.1.0

Allright, after some debugging, I found the root cause (for my case, but maybe it can help for other people who have the same issue) It was because the environment property of my idtoken did not match any of the knownauthorities of the auth config (the config object passed when initializing the msal instance)

Details: The method CacheManager.getIdToken() wasn’t able to return the IdToken from the browser cache. It was successfully able to retrieve all idtokens from the cache (which in my case, there was only one) but failed to validate it against my config. It tries to match it against the clientId, homeAccountId, environment and so on. In my case, it didn’t match on the environment <-> knownauthorities because I had used the same value for ‘knownauthorities’ than for ‘authority’ and it was slighly different (I’m using ADFS)

I just added the environment to my list of knownAuthorities and it immediately worked. In my case I just had to lop off https:// in front where I specified the knownAuthority. Nice find!

Core121 on Dec 6, 2023

Thanks for the comment @jingfee. That’s quite possible, I did bump up those versions in the same go when I upgraded to Angular 17. But I tried to downgrade to the previous versions msal-angular (3.0.4) and msal-browser (3.1.0) when I was on Angular 17 but the issue remain. Possible I did some mistake in the downgrade and the node_modules wasn’t representative, I’ll give it another try.

Keep in mind if you downgrade but still have the ^-prefix it won’t downgrade (for example “^3.0.4” instead of “3.0.4”)

jingfee on Nov 14, 2023