Not sure if this is a good idea or if there is a much simpler way to enable this, but I am able to get the user profile on the React client-side of my app using the user object from the Auth0 context provided with the Quick Start code. I can authenticate correctly on my ASP.Net Core API and retrieve the user id which is perfect. However, I cannot seem to figure out how to get the other user information on the API side (such as user nickname/profile name, email, etc…).
Is there a way to add this into the JWT when calling the API as additional claims? Or should I use the Manager API client (not looked into how that works yet, or tried setting it up)? I would like to be able to send customised data from the API depending on the profile name (i.e. the nickname). Is this possible?
Also, I want to be able to store customized data as a claim for authorization. Should I store this in the database and keep querying it each time per request using the user_name/id from the JWT as a key, or can I store this inside the JWT (things such as the id of their account, etc…)? If so, how?
The userinfo endpoint is where you can get the normalized user profile. I think this is the answer for your question, but let me know if it is not. Check out the doc for it here: https://auth0.com/docs/api/authentication#get-user-info
This would be a good use of metadata. You could technically use the management API, but if you want this piece of data in every authentication then you might as well add it to a token and save yourself the extra requests. You can add the metadata to your tokens as a custom claim via a rule. There is an example of that here: https://auth0.com/docs/scopes/current/sample-use-cases#add-custom-claims-to-a-token
Can you give me an example of this or provide more information?
The answer to this is likely going to depend on the data. If it is auth related, then you could store it in metadata (see the doc above). If it is not related to auth, it is recommended to use a different DB for that data. It is also going to depend on size of the data, as there are limits to what the metadata properties can handle.
If you choose to add it to the token that can be done through the example I mentioned above.
Hi @dan.woda, Thank you for the very helpful reply.
I eventually figured this out but not sure if I should request a new token first. On the API side I obtained the same token the user used in the Authorization header to make a query to that end point. It seemed a bit hacky but is this the recommended way?
This is exactly what I needed to know. I’ll try that out tonight, thanks!
I thought adding the “nickname” to the token as a claim might be useful so that when I send a verification email using the API backend (I have an email service using SendGrid), or any other type of email, I could build it with the nickname. I know there are other scenarios where i would need the nickname so I was suggesting that maybe the nickname (or profile name) might be useful as a claim. But I could reuse the authentication endpoint now that you’ve mentioned it.
With the “custom” application data, I’m having the problem of knowing when I should create this data which is a root problem of the last thing I mentioned. I’ve followed the Quick start React.js SPA documentation which exposes:
and I can add a callback for when the user logs in on auth0, but how can I detect when the user first signs up (e.g. a new user is created on Auth0)? Because I need to redirect them to my API to create their initial business account (custom web application specific logic). I would also like to show a welcome page and send a verification email using the API but cannot figure out how to hook into this event. If I knew that then it would make the data flow/user journey so much easier to implement. Any advice would be great.
There are many ways you can handle retrieving user data. For example, you can store a copy of the user info on a DB on your side, limiting the amount of outside calls you have to make to retrieve data. You could also ping the userinfo endpoint every time you need data, as it has a fairly high [rate limit] (Rate Limit Policy) per user, and shouldn’t cause a problem. If you know you need a specific piece of data, adding it to the token in a custom claim is another option. There are drawbacks and benefits of each of these solutions (rate limits, efficiency of making outside calls, adding to the size of the access token, having to manage your own user DB etc.) and you must evaluate what works best for you. Our goal is to provide you with the tools you need to create the most effective solution for your use case.
This would certainly be an opportunity to add a custom claim. Alternatively, you can hook up your send grid service to auth0 emails and have a custom email template for a verification email. You can then call the managment api post_verification_email endpoint and start a verification email flow. This requires that you only have the userid, which is already in the token. Either method works, it will just depend on what works best for you.
There are again a few ways to do this (you are probably seeing a theme here), you can utilize a post registration hook to have actions run asynchronously after a user registers, or you can write a rule to force email verification. You can also write a condition in that rule to simply prompt for email verification after first login using a the context.stats.loginsCount property. There may already be a rule for this, I’ll have to check.
For user sign up and creating their initial account you can redirect from a rule, or you can simply change the redirect url to the one you want based on that same logins count property I mentioned above.
I know this is a lot to absorb, so please don’t hesitate to ask more questions or let me know if I missed something.
Thanks, Dan. That’s a lot of reading material but very appreciated. I think my main confusion came from using the library recommended in the Quickstart for React.js. I am using:
import createAuth0Client from '@auth0/auth0-spa-js';
and the client created from that only has 1 method exposed: loginWithRedirect , so I thought that was my only callback. I found the documentation here but there doesn’t seem to be any mention of the signup process (for creating new users) at all. I’ll read up on the post-user-registration articles you sent, but can this be integrated into a React.js SPA with the newer client? Or does it call the API?
The user registration hooks can be configured in the dashboard and run completely separately from your app.
Spa.js will initiate the redirect or popup and can be used to sign up or log in. Or you can call the authentication endpoint if you want a custom signup page: https://auth0.com/docs/api/authentication#signup