Logged In User Information

[MountainTopTech]

I’m really confused on how to get additional information about a user once they log in. I have a sample Blazor server app and am able to login but the only thing I can see is the users name (user.Identity.Name). I’ve looked at all of the documentation and samples and just keep going in circles on how to basic stuff.

When I try to access the email address for the logged in user, it is blank. Do I have to add that field to the claims in the dashboard or a scope somewhere?

protected override async Task OnInitializedAsync()
{
    var state = await AuthState.GetAuthenticationStateAsync();

    Username = state.User.Identity.Name ?? string.Empty;
    NickName = state.User.Claims
        .Where(c => c.Type.Equals("nickname"))
        .Select(c => c.Value)
        .FirstOrDefault() ?? string.Empty;

    await base.OnInitializedAsync();
}

On the state.User.Claims object, I was able to only see the following properties: name, nickname, picture, updated_at, “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier”, and sid.

[tyf]

Hey there @MountainTopTech welcome to the community!

Thanks for the detailed description of the issue - While I’m not super familiar with our ASP.NET CORE SDK, you will need to include the email scope when configuring the it. I believe this may be what you are looking for:

https://auth0.github.io/auth0-aspnetcore-authentication/api/Auth0.AspNetCore.Authentication.Auth0WebAppWithAccessTokenOptions.html#Auth0_AspNetCore_Authentication_Auth0WebAppWithAccessTokenOptions_Scope

Hope this helps!

[SaqibHussain]

Hi @MountainTopTech
As well as what my colleague @tyf said, I think the Blazor implementation will query the /userinfo endpoint to populate the Id Token with the standard claims. If you need the other claims associated with the user profile you may need to create an Action to copy those into the Id Token. Something like the below should do the trick depending on what you need from the user profile:

exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://my-app.example.com';
  api.idToken.setCustomClaim(`${namespace}/email`, event.user.email);
  api.idToken.setCustomClaim(`${namespace}/user_metadata`, event.user.user_metadata);
};

I tried this out on my Blazor app and got the below when enumerating through my claims:

Hope this helps.
Warm regards.

[MountainTopTech]

Not sure how that helps me.

[MountainTopTech]

I’ve added the custom action but not sure what to use for the namespace? Do I need that?

I tried looking for the email claim that is in the action but nothing shows up.

[SaqibHussain]

Hi @MountainTopTech

Best practice is to use namespaced claims to avoid any sort of name collision. The namespace could be your own domain for example. If you have good reason you can now leave off the namespace but follow these guidelines https://auth0.com/docs/secure/tokens/json-web-tokens/create-custom-claims#non-namespaced-guidelines

So you’ve created a Post Login Action and are adding email from the user profile to the Id Token but you cannot find it in your application when logging in?

Try putting some console.logs in your Action to ensure it’s executing and inspecting variables and use the Real-time webtask logs extension to view the output of those logs.

If you’re happy it’s executing try looping through the claims in your app post login to check it is there.

Warm regards.

[MountainTopTech]

I feel like I may be close. This is my post login action which I deployed:

exports.onExecutePostLogin = async (event, api) => {
  api.idToken.setCustomClaim(`email`, event.user.email);
};

Then I realized that I did not add it to the Flow so I have added to the flow and applied as follows:

When I try to get the claim in the app, I do the following but is still empty:

Email = state.User.Claims
  .Where(c => c.Type.Equals("email"))
  .Select(c => c.Value)
  .FirstOrDefault() ?? string.Empty;

I tried adding the logging extension and running it but nothing appears in the log. When I test the action, the log appears with the email value. What triggers the Post-Login action? Maybe I need to set that up somewhere or does that happen automatically?

[SaqibHussain]

Hi @MountainTopTech

Sounds like you’re making great progress. Forgetting to add the Action to the flow…I’ve been there more than once

I’m assuming you have a console.log at the top of the Action so you can see that it executes. I’m also assuming you’ve added your Action to the login flow as are a few flows available. If so then we should be seeing that console.log appear in the logs extension when you login via Universal Login. This is how we can prove that your Action does execute. Just ensure you hit the Apply button when you added your Action to the login flow as that has got me a couple of times too.

Once we know for sure that the Action does execute whenever you login to your application via Universal Login then your claim should come across into state.User.Claims.

Warm regards.

[MountainTopTech]

I have the following code in my action:

exports.onExecutePostLogin = async (event, api) => {
  const namespace = 'https://mynamespace.com';
  console.log('email: ' + event.user.email);
  api.idToken.setCustomClaim(`${namespace}/email`, event.user.email);
};

I have applied the flow and everything looks deployed.

The only thing I don’t understand is I am never calling the authorize endpoint from my Blazor Server app unless it is handled under the covers. In my index.razor page, I have the following code:

@code {
   private string Username = "Anonymous User";
   private string UserId = "";
   private string Email = "";

   protected override async Task OnInitializedAsync()
   {
       var state = await AuthState.GetAuthenticationStateAsync();

       Username = state.User.Identity.Name ?? string.Empty;
       UserId = state.User.Claims
           .Where(c => c.Type.Equals(@"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/nameidentifier"))
           .Select(c => c.Value)
           .FirstOrDefault() ?? string.Empty;
       
       // Remove Auth0 prefix
       UserId = UserId.Split('|')[1];

       Email = state.User.Claims
           .Where(c => c.Type.Equals(@"https://mynamespace.com/email"))
           .Select(c => c.Value)
           .FirstOrDefault() ?? string.Empty;
       await base.OnInitializedAsync();
   }
}

What I don’t understand is how it knows to execute the Login flow for the application because right now, the email claim is not getting to the application. What am I missing?

[SaqibHussain]

Hi @MountainTopTech

Apologies for the delay in getting back to you on this.

My first question is did you confirm via the real-time webtask logs extension that the Action was indeed being executed i.e. the email was being sent to the logs as per your console.log?

On the Blazer app, the login is mostly under the hood (there could potentially be other implementations you could use giving you some control) but when you login you may get an Id Token, fire up the browser dev tools and then execute the login flow, you should see the /authorize, when you login you may also see a token:

which contains an Id Token:

If you inspect the token in https://jwt.io/ you should see the custom claims there.

Warm regards.

[MountainTopTech]

I can never get the real-time webtask logs to show anything. I read somewhere they only work with Rules and not Actions. Is that true? I don’t know if you can look at my setup and see if anything is wrong. I don’t know what else to try.

[tyf]

Hmm you should be able to see a console.log in the real-time webtask extension, however I’m currently not able to see any logging either. Another option is to inspect the “Successful Login” event in your dashboard at Monitoring → Logs. Any logging you add to your action will be printed here:

[MountainTopTech]

The only logs I have are API Read Operation and nothing else. The filter is set to All with All Dates.

[MountainTopTech]

Just a quick update.

I guess I needed to wait some time after deploying (how long I don’t know since it’s been 10 days since I am revisiting this) but now the logging shows the email claim logging and coming back to the client.

[tyf]

Interesting, that’s good news though! Thanks for following up here