JwtSecurityTokenHandler missing claim mapping for "name"

[thomaslevesque]

The name claim is a registered JWT claim for the user's full name (https://www.iana.org/assignments/jwt/jwt.xhtml)
However, it isn't included in the default mappings, unlike given_name and family_name.
It should probably be mapped to ClaimTypes.Name. Is there a reason for this, or is this just an oversight?

Workaround: execute this when the app starts:

JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Add("name", ClaimTypes.Name);

[brentschmaltz]

@thomaslevesque claim mapping is an interesting subject, most of the feedback we have received is that we should not map any claims.
How do you use claim mapping?

[thomaslevesque]

@brentschmaltz, actually, I agree with the idea that no mapping at all would be better. But if there's a mapping, it might as well be done right. I know I could disable the mapping completely, but since it's done by default and everybody is used to it, I usually don't bother.

[AlexandreArpin]

👋

Just upgraded from 6.8 to 6.9 (AspNet Core 3.1) and experienced a breaking change.

I'm not super well versed in all things OpenId/Authentication/etc, but one of the side effect of this change was that now for some reason the "name" claim was now being mapped as http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name instead of name when using OpenId OnTokenReceived (We use OpenIdConnect, ADAL, Azure AD V1 Application and Work Account login).

We updated our mapping/claims logic to work on both versions, but we were rather lucky to have caught it (it's an Api surface that's rather difficult to unit test).

[brentschmaltz]

@AlexandreArpin we will have to roll this back, in the meantime, there is a workaround.
You can remove the entry from ClaimTypeMapping here:

azure-activedirectory-identitymodel-extensions-for-dotnet/src/System.IdentityModel.Tokens.Jwt/JwtSecurityTokenHandler.cs

Line 60 in 7d3571f

public static IDictionary<string, string> DefaultInboundClaimTypeMap = ClaimTypeMapping.InboundClaimTypeMap;

[udlose]

@AlexandreArpin we will have to roll this back, in the meantime, there is a workaround.

@brentschmaltz so is this going to be changed again in the future or do you mean, we shouldn't have done that and it will remain as it was in v6.8.0 before #1545 ?