Auth0 Home Blog Docs

GetUserInfoAsync not returning all data for a user

I am trying to get the properties of the currently logged in user after they successfully log in. I am doing this using C# and the AuththenticationApiClient object.

var claimsIdentity = User.Identity as ClaimsIdentity;
string accessToken = claimsIdentity?.FindFirst(c => c.Type == "access_token")?.Value;
string idToken = claimsIdentity?.FindFirst(c => c.Type == "id_token")?.Value;

AuthenticationApiClient client = new AuthenticationApiClient(new Uri(string.Format("https://{0}", ConfigurationManager.AppSettings["auth0:Domain"])));
var profile = await client.GetUserInfoAsync(accessToken);

The profile object is created with the user, but the firstname and surname properties are returning as null. I have verified that the firstname and surname properties have been set for my user by looking at this information in Auth0 under the Users > Identity Provider Attributes.

Thoughts as to why these values are null, where as others like the users id, email, and even app_metadata are returned?

GetUserInfoAsync uses OIDC’s /userinfo endpoint. In OIDC, the information that gets back to the application both in the ID Token and in the /userinfo endpoint are affected by:

  • The additional claims added by rules.
  • Other custom transformations made by rules (like removing the first name and surname on purpose)

The .Net SDK puts additional claims (those that don’t have a property associated) in the AdditionalClaims dictionary. This class shows you how the mapping is done: https://github.com/auth0/auth0.net/blob/master/src/Auth0.AuthenticationApi/Models/UserInfo.cs

You can also inspect the idToken coming from line 3 in the above code snippet and decode it at https://jwt.io. This will show you the claims coming in the ID token (which will contain roughly the same user claims as the user info). If the ID Token has the first name and surname, then something is wrong on the .Net SDK side (maybe the claim doesn’t have the expected name). If the claims are not there, then something is wrong on the server side (e.g. a faulty rule, or incorrect user profile).

If the above doesn’t help, please provide the tenant name, the user ID involved, and a .HAR file capturing the authentication flow.