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)
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)
@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.
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!
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”)