OpenId/AzureAd - wrong value in HttpContext.User.Identity.Name in .net core 6

Question

Our project uses Azure AD to authenticate users.

After migration from .net core 3 to .net core 6 we started to get Claim with type "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name" twice. You can see that on my screenshot below. One is, basically, full name of a user (John Doe) and another one is an email address that we need.

This breaks our auth code now as we were using HttpContext.User.Identity.Name to find user in our database. That property takes value for .Name from claim with type mentioned above.

Under .net core 3 we were getting both of those claims, but full name had a simple type "name" and one with email address - "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name". And that worked great. Now, as we receive same claim type twice - first one is being populated to .Name and that is full name instead of an email address which we want.

I have some workarounds already.

One is changing source claim type for .Name property:

options.TokenValidationParameters.NameClaimType = "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn";

Another one, with a simple class that implements IClaimsTransformation interface, allows me to remove/fix duplicate Claim Type and make it work like before.

But both of those solutions are not ideal. UPN does not guaranty that it will be the same as /name claim (and we have a lot of users that are registered using ../name value) and as far as I understand - it might be not available at all. And second solution is not reliable as it is hard to distinguish full name and that email address (someone may put @ to user's full name or a field with address may send us something that is not in a shape of email address).

So, question is - what may cause this issue? What may control this? I think this is something to do with recent changes in .net as we have done nothing to our Azure AD config. And old code still works fine with it.

Answer 1

Thanks for reporting back to your own question. We faced the same issue with one of our products that had an indirect dependency to version 6.10.0 of System.IdentityModel.Tokens.Jwt after updating some direct dependencies.

It really got us puzzled why this one product suddenly had login issues. Your solution helped us in the right direction! :)