NameClaimType Doesn't Seem like Validation in TokenValidationParameters

Apparently one must configure where to get the user’s name claim from so that they can perform operations like var name = User.Identity.Name;

In the following Azure-Samples/active-directory-b2c-dotnet-webapp-and-webapi example, the value is configured via TokenValidationParameters.

That doesn’t feel right to me. It is not validating the name claim, it is telling it where to find it, no?

app.UseOpenIdConnectAuthentication(
	new OpenIdConnectAuthenticationOptions
	{
		// Generate the metadata address using the tenant and policy information
		MetadataAddress = String.Format(AadInstance, Tenant, DefaultPolicy),

		// These are standard OpenID Connect parameters, with values pulled from web.config
		ClientId = ClientId,
		RedirectUri = RedirectUri,
		PostLogoutRedirectUri = RedirectUri,

                ....

		// Specify the claims to validate
		TokenValidationParameters = new TokenValidationParameters
		{
			NameClaimType = "name"
		},
	}
);

---

nameClaimType

Sets the claim type that specifies the Name property. The claim type is used to search for a Claim in the collection of ClaimsIdentity objects returned by the ValidateToken method of this token handler. The value of the matching claim is then set as the name of the IIdentity generated from this token handler.

---

Reference: Azure AD B2C: User.Identity.Name is null, but User.Identity.m_instance_claims[9] has the name

Reference: https://github.com/aspnet/AspNetKatana/issues/186

[brentschmaltz]

@spottedmahn we will ping you when we start the async work.

[brentschmaltz]

@spottedmahn I get your point. Controlling the result of ClaimsIdentity.Name is probably not what one thinks about when validating a token. It is a separate step, ClaimsConfigurationParameters (or something named like it) may be a good container for all the settings one may want to use. I’ll reopen for now, and let’s think about it. We want to get a release ready by mid april. So I don’t think it fits this release. A future release will have an async pattern and will require new apis. Passing in a context returning a result may naturally fit into that.