Cannot see userinfo in Api endpoint

Platform: C#, Visual Studio ASP.NET 2.0 Core

I’ve been following these two tutorials & in order to make my Angular-spa call my .net core Api. It all seems to work fine with simpel Authorization on the individual endpoint. However, when I try to add profile and email to scope I do not see anything in the claims at the Api endpoint .

What I’m actually trying to do is to see the userinfo at the Api endpoint when a user tries to login and call an endpoint. As far as I understand I have to use scope for this but maybe I’m missunderstanding something?

I’ve set my Angular scope to “scope: ‘openid profile email’,” as explained in the angular2 tutorial

auth0 = new auth0.WebAuth({
    clientID: AUTH_CONFIG.clientID,
    domain: AUTH_CONFIG.domain,
    responseType: 'token id_token',
    redirectUri: AUTH_CONFIG.callbackURL,
    scope: 'openid profile email',
    audience : AUTH_CONFIG.audience,
    client_secret : AUTH_CONFIG.client_secret,
    grant_type : AUTH_CONFIG.grant_type

And I’ve keept everything in my .net Core Api as described in the aspnet-core-webapi tutorial

public Task Get(string profileId)
var authorization = this.Request.Headers[“Authorization”].ToString();
var tokenstring = authorization.Substring("Bearer ".Length).Trim();
var handler = new JwtSecurityTokenHandler();
var token = handler.ReadJwtToken(tokenstring);

        var principal = HttpContext.User;
        if (principal?.Claims != null)
            foreach (var claim in principal.Claims)
                Console.WriteLine($"CLAIM TYPE: {claim.Type}; CLAIM VALUE: {claim.Value}");

        return GetProfileByIdInternal(profileId);

There’s a few things to have in mind in this situation, in particular:

  • adding openid profile email to the scope means that you want to received an OpenID Connect response (obtain an ID token) and that within the ID token you should receive information about email and profile attributes.
  • when having a client application (Angular) and an API (.NET) that are treated independently (each have their own record in the corresponded section of Auth0 dashboard) the token that will be used by the client application in API calls is the access token.

From the above comes that if you’re sending an access token to the API then asking to receive user information as part of the ID token won’t immediately help because you won’t be sending the ID token to the API.

In this situation, you can consider explicitly adding information to the access token through rules ( or if the API is configured to use RS256 then the issued access token will also have and audience valid for the /userinfo endpoint and the API could call the user information endpoint to get the requested user information (this second option may have considerable overhead).

Hi jmangelo,

Thank you for your reply :blush:

I’ve looked at your link and as I understand it I can use the standard OIDC scopes such as profile and email without having to create any custom claims. However, when I debug my Api endpoint I can only see the {scope: openid profile email} as one of the claims but not their actual values.

I don’t really want my Api to make another call to Auth0 in order to simply get a name or email so it would be best to add the information to the access token like you say. However, I don’t see how this is done in either of the two tutorials I’ve been using ( & and it’s not clear either from the link that you provided. Do you know of any good code sample or tutorial that shows this for a newbie to Auth0? :blush:

What I’m trying to do, is simply to get some type of id (name, email or other) that my Api can use to find the user in my database when a user calls the endpoint after authenticating.

Thank you in advance for all your help :blush:

You can use the OIDC scopes (email profile) to influence the contents of the ID token, not the contents of the ACCESS token.

In a scenario where you have an independent API what you actually send to the API is the access token so that’s why I mentioned custom claims.

However, my mention of custom claims is in the context of an access token; not the ID token. Something like:

context.accessToken[""] =;

You can get an email claim automatically in the ID token by using the email scope, but since you’re using an access token to call the API this would be mostly irrelevant.

Sorry I don’t understand where does the “context.accessToken[“”] =;” go? Into the .Net Core API code or at the Angular SPA end?

I’ve been trying to look at customs claims and rules, but I cannot find any good explanation, code sampels or tutorials for a .Net Core API with an Angular SPA where it is clear what I exactly have to do in order to get the users identity. The documentation & are a bit too generic and not very clear for a newbie.

The above snippet should be used as part of a rule as mentioned in the custom claims documentation section you linked to.

With regards to getting user identity it depends; for a client application the most common situation woud be to obtain it through the use of an ID token that will both have a claim sub that contains a unique user identifier and which also may contain OIDC claims representing user information.

For an API making use of OAuth 2.0 access tokens as authorization mechanism, the currently issued access token will be a JWT that contains a sub claim that will also uniquely identify the user. If the different types of tokens (ID tokens vs access tokens) is something that you have queries about the docs at ( may be useful.

Hi jmangelo, I tried adding the Custom Claim using a rule in order to add the email to the Access Token, just like you said. However, I still cannot see anything in my Api when it is called.

function (user, context, callback) {
context.accessToken[“https://something/api/v2/email”] =;
callback(null, user, context);

As you can see from this screenshot there is no sign of any custom claims


The Startup.cs file and everything in the Agular project are exactly as described in the two tutorials mentioned earlier.

For troubleshooting purposes try this exact line context.accessToken[""] = "X"; as this uses an hardcoded value so it’s always defined and also an allowed domain for namespacing.

For example, if the something in your example is then the custom claim would not be included because there are certain domains that are blacklisted.

Hi jmangelo, That seemed to work! It was just the domain for the namespace that was not valid.
Thank you very mcuh for all you help. :slight_smile:

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.