0
votes

When switching from adal to the msal 2.0 browser library, I'm missing the UPN of the user in the idToken response, which leads to a principal that doesn't have a name in principal.Identity.Name after passing the idToken to the backend. This was available in the adal version.

var principal = tokenHandler.ValidateToken(validationToken, validationParameters, out SecurityToken validatedToken);

I get preferred_name as a claim, but it doesn't seem to be usable to call the Graph API to retrieve an email address, as it's not a UPN.

How do I need to change token validation and UPN retrieval for msal in general? Pass the accessToken and validate that separately to get more claims?

Docs for idToken

Docs for accessToken

Code sample

1
IdToken is in a certificate. The certificate is not loaded or is not accessible to the user. The certificate is validated using a virtual connection and the connection may not be completing. Suspicion is the code is using the default version of TLS which is 1.0/1.1 and you need to specifically add TLS version to use 1.2/1.3. Five years ago the industry decided to eliminate 1.0/1.1 due to security issues. This June Microsoft pushed a security update disabling 1.0/1.1 on servers. Old example code may not have updates for using 1.2/1.3. Certificate also need to be using correct encryption mode. - jdweng
Sorry my question might have been unclear. I’m talking about this here docs.microsoft.com/en-us/azure/active-directory/develop/… - Benjamin E.
The documentation is not clear where the key comes from. Even the RCP specification is confusing (tools.ietf.org/html/rfc7517). JWK is the JSON Web Key. You link refers to the JWT (Jason Web Token). I think the token and key are the same. So if you look at para 4.6 of RFC 7517 it refers to the certificate. The key doesn't have to come from the certificate, but certificates are the normal method for distributing the keys. Your documentation is referring to the application layer while the transport layer is using TLS authentication. - jdweng
I have a feeling we are talking about very different things :) - Benjamin E.
No. You are looking at the only application layer and I know what is happening at the lower levels. - jdweng

1 Answers

0
votes

Turns out msal supports 2 ways to get additional claims

  1. Via AD manifest settings
  2. When requesting a token as below

by adding additional scopes

const loginRequest = {
    scopes: ['User.Read', 'email']
};

and when validating a token different claims can be used to get the principal's identity by setting TokenValidationParameters.NameClaimType