Auth0 Home Blog Docs

Update a user API does not allow updating name

user-creation
users
user-profile
user
profile-update

#1

When I create a new user by API it is possible to provide a field “name”.
If I don’t provide this field at the time of creation, then Auth0 fills it with user email.
Later on when I want to update user’s name, strangely enough API does not accept “name” field anymore.


#2

I have registered your feedback about this situation, however, at this time I cannot provide you with additional information if this is will be supported or when. Also note that, to my knowledge, the creation part is not documented as supported so purely from a docs perspective it’s not an inconsistent behavior.

As an already available alternative, if you’re looking for an always editable data store available as part of your account and that can be managed through the Management API then, at this time, you should consider using user_metadata and app_metadata.


#3

It’s pretty frustrating to have a name attribute used in all the responses, and sprinkled throughout the actual auth0 UI w/ no ability to actually update the value.

If this is a deprecated field or something are there docs somewhere I can reference to identify fields we shouldn’t use?


#4

It’s pretty frustrating to have a name attribute used in all the responses, and sprinkled throughout the actual auth0 UI w/ no ability to actually update the value.

If this is a deprecated field or something are there docs somewhere I can reference to identify fields we shouldn’t use?


#5

At this time, if you always want to have control over the data then using the metadata is likely the best option as other root fields on the profile may not be controllable in all scenarios. We also understand that the situation around user profile fields and ability to edit them or not is confusing and it’s our intentions to work on this situation, but as mentioned I cannot provide you with definitive timelines.


#6

Bump on this - any update? The inability to update the ‘name’ attribute is honestly incredibly frustrating and ridiculous, considering that there’s no way to choose to use the user_metadata attributes in SAML assertions through Auth0. cc @jmangelo


#7

Bump on this - any update? The inability to update the ‘name’ attribute is honestly incredibly frustrating and ridiculous, considering that there’s no way to choose to use the user_metadata attributes in SAML assertions through Auth0. cc @jmangelo


#8

This limitation has proven problematic in my use case. If I’m forced to use the user_metadata.name:

  • The name does not display on the User Detail page. Instead the email is displayed. I have to scroll down to see user_metadata.
  • The name claim in the id token is the user’s email… In order to change this behavior, I would have to write a custom rule.
    Is there a specific reason that editing of name is not allowed?

#9

It’s an inherent limitation of the current implementation which it could be argued that it does not make sense and I would agree with that reasoning. Although there are plans to review the user management situation at this time I don’t have any concrete information to share. Ideally this limitation will not be present in the future and no workarounds/hacks will be necessary.


#10

Chiming into the debate here…
This issue is less of a concern for me as a developer.
My site admins (end users/clients) find it confusing and frustrating that they cannot search by a field clearly labeled ‘Name’ on the Users Dashboard.
With all the good that Auth0 brings to the table something like this can be a deal breaker for the people that we as devs need to pay for the service.


#11

What’s the current leading internal thought here? Isn’t this a core functionality of Auth0?


#12

Have in mind that the ability to associate a name to an end-user independently of the underlying identity provider is available through metadata. This makes sense from the perspective that when a user authenticates through Facebook the root profile properties come from Facebook and cannot be overridden by Auth0. The same does not make sense when the end-user authenticates through a database connection in which the service itself is the definitive identity provider, however, the current implementation does not cater for this. As mentioned before this is something we want to review.


#13

I just stumbled upon this as we are implementing auth0. Hope this is reviewed soon.

In the meantime, this is not so easy to discover… it would be great if there was some clear note/explanation about the “name” field and how it functions in the documentation that you encounter when you are new to auth0.

In the current documentation we found references to name, family_name, given_name, user_metadata.first, user.metadata.last etc…

By trial and error we discovered that if we set user_metadata.name it shows, in the list of users under name in the auth0 dashboard, but not on the user detail page, and as noted, you can’t search on it in the dashboard. Confusing to say the least, but even more so when the documentation is not clear about any of this.


#14

This issue makes me want to rage quit auth0. Possibly a deal breaker if it’s not fixed before I have a chance to refactor it out for an open source replacement.


#15

This issue makes me want to rage quit auth0. Possibly a deal breaker if it’s not fixed before I have a chance to refactor it out for an open source replacement.


#16

I understand your frustrations and like I mentioned before it’s tracked in the backlog, but I’m afraid at this point the only thing I can continue to do is to relay the feedback internally and reflect that in the backlog item used to track this.


#17

It’s also worth noting that the API docs don’t even show “name” as a parameter that can be passed – all of the users created through our custom provisioning tool thus have their name as their email address and that’s what we’re stuck with for all SAML service providers.


#18

In relation to the API docs, the name parameter is not shown neither in create or update, if I recall correctly, which is correct in terms of support because update does not support it and having only documented in created would not make sense.

About the mapping for SAML, do you mean you tried something like (https://auth0.com/rules/saml-attribute-mapping) and it did not work?


#19