I’m finding myself generally confused with how to handle basic user profile information in an Auth0 database connection, and how that fits in to a returned id_token once the user is authenticated. For the purposes of this question, I’ll use name as an example, but this also seems to pertain to picture and nickname.
It’s my understanding that directly modifying the name property on a user in Auth0 is impossible. The recommended approach is to define name in the user_metadata field. In the Auth0 dashboard, I have defined the following user_metadata for my user…
{
"name": "John Smith"
}
When I request the full user profile through the management API, I get something like this…
{
"name": "john@gmail.com",
"user_metadata": {
"name": "John Smith"
}
}
Okay, so at least I can get the name like that, but that seems like it completely defeats the purpose of the id_token containing some minimal information about the user, such as the name. If I decode the id_token JWT, I do get a name field, but it does not match the name field in user_metadata. So, essentially, to get basic user info about a user, I’m forced to use the management API to fetch their entire profile.
To add to the confusion, I do notice that in certain places, such as the Auth0 users dashboard, that it is respecting the user_metadata name and using that instead of the root-level name field on the user. I would assume that then the name field in id_token or even the full user profile would be similarly “overridden” but this isn’t the case.
Is there anything I can do to streamline this a bit? I’d like to minimize the number of odd workarounds if possible for what seems like a very basic, common, and universally required feature of user authentication.
You have a point and the way user information can or cannot be managed, in particular, when focusing on database connections is confusing. We acknowledge this situation and intend to change things around this area and hopefully make it simpler, however, since there’s a need to handle prior usage and also review any possible breaking changes this is unlikely to happen from one day to the other.
Having said that and focusing on your particular problem, you can consider using app_metadata instead and store the name there; a few quick tests show that if the name property exists at that level then the name claim in the issued ID token will have the corresponding value. The downside is that I could not find any formal documentation on this behavior. However, I wanted to mention this because it’s something you could also find yourself through experimentation and you may deem it acceptable.
As another alternative and one that you always know it would work would be to include the additional information you require in the ID token as custom claims; it’ a bit awkward when the information in question is more suitable for standard OIDC claims, as name would be, but in this way you’re in total control.
Thank you for your answer! I hadn’t tried app_metadata. Once I moved the name, picture, nickname, etc. overrides there it did indeed start coming back as part of the basic claims as expected. This is perfectly acceptable.
Regarding custom claims, that is what we were actually doing, it just seemed a bit counter-intuitive, but you’ve cleared it up. Once again, I really appreciate the help!
So after playing around a bit more, I’ve hit another wall. While adding fields like name to app_metadata does indeed override the values in the ID token, it now seems like there is no way for the user to change app_metadata. We’re once again in a scenario where user-modifyable details such as name and picture are not actually user-modifyable. Do I need to fall back to custom claims?
Sorry for the back and forth, but if there’s also a requirement of direct control by end-users then you could consider going back to user_metadata and then in a rule do something like user.name = user.user_metadata.name; which, again based on quick tests and not formal documentation, would get you the behavior of having the value in the issued OIDC standard claim of name.