Default 'sub' claim mapping does not resolve to ClaimsPrincipal.Identity.Name

To process a JWT, the API consumer is going to use most likely the JwtSecurityTokenHandler.ValidateToken method, to get a ClaimsPrincipal.

RFC7519 states for the registered ‘sub’ claim (emphasis mine):

The “sub” (subject) claim identifies the principal that is the subject of the JWT. The claims in a JWT are normally statements about the subject. The subject value MUST either be scoped to be locally unique in the context of the issuer or be globally unique. The processing of this claim is generally application specific. The “sub” value is a case-sensitive string containing a StringOrURI value. Use of this claim is OPTIONAL.

The ClaimsPrincipal object returned from the ValidateToken method allows to identify the subject via its default interface with the Identity.Name property only. There are no other default properties that expose a principal identity unless you’d query the claims.

Because the default mapping of the claims controlled with ClaimTypeMapping links sub to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier, it does not match with the claim http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name used to query the Name property.

Therefore, when a JWT has the sub claim only, there is no easy API to access its value.

The default mapping should be changed to http://schemas.xmlsoap.org/ws/2005/05/identity/claims/name, so that ClaimsPrincipal.Identity.Name resolves to the sub claim.

[leastprivilege]

I personally think it is evil that the JWT handler converts the standard claim types to the Microsoft favoured ones.

you can turn that globally off by setting the static DefaultInboundClaimTypeMap property on the JWT handler.

After that - yes do a FindFirst on sub.

[mattjbrent]

For anyone hitting this with this issue - any ASP .NET 5 API you work on that is receiving JWTs, you need to ensure JwtSecurityTokenHandler.DefaultInboundClaimTypeMap.Clear(); gets called at the top of your ConfigureServices method in Startup otherwise standardized claim names will get transformed to legacy XML names.

This is especially pertinent in a microservices architecture - this will need to be added to ALL API Gateways and ALL microservices to ensure that any tokens that are passed downstream don’t get auto-magically changed into the old legacy formats.