I need to be able to set both name and email after initial user creation / login. The OIDC provider I use only has a unique identifier for the users, but no name or email address.
I have created a post login form where I want the users to type in their name and email adress. I am able to add the information to the user_metadata property, but when trying to store it directly on the user in the “name” and “email” properties nothing happens. Flow is executed without any errors..
I will be testing this in the meantime on my end and will come back with some updates. Otherwise, could you please let me know how do you set those properties inside the Forms Flow that you are using?
Also, are these properties available under the user in the Dashboard after the login is complete?
As far as I have tested, it appears that when I am setting the values inside the email and name properties directly, both of them get populated accordingly as seen below:
It appears that the email property might not be passed to the ID Token because it is not an available attribute inside the database connection you are using, however, it is set inside the Dashboard. I would recommend to add the email attribute as well so that users can create an account using an username and email or you can add the email as a custom claim inside an action:
Oh, sorry, I must have missed the part where you stated that this is done through an OIDC connection. However, the results should be the same since the profile attributes should be the same inside an user who signed up through your application normally or retrieved through an IdP.
I will double check the results using different OIDC connections and provide you with an update nonetheless!
After some testing, it appears that the retrieved user profile cannot be modified through Auth0 directly. In order for the Management API to be able to modify user data, they would need to be stored via a Database Connection or Passwordless connection.
In order for your to update the user with such information, you either need to add these elements as user_metadata as you have attempted above or you would need to make an API call to the IdP in order to add these attributes to their profile so that they are retrieved after login (if the IdP can support them).
We need a manual flow where the user inputs this information. The IdP does not provide this information, and will not do it either. There isn’t any APIs either. The problem with this is that the user list becomes completely useless as it just says “(empty) (empty)” on all the users.
Are there any other workarounds, or is this something that can be fixed?
I actually got it working! I had to change the sync frequency on the enterprise OIDC connection to “Only at first login”. This allows you to edit the root properties of the users
Some further testing at my end. I am now able to update the root name property of the user on login, but if I try updating the email property it looks like the login is successful, but none of the properties are updated.
So, if I add email in the json, both name and email fails. No error logs or nothing. As soon as I remove email from the fields to be updated it starts working again. The name is changed.
Do you have any suggestions on how I can achieve this? One observation is that when I inspect the raw JSON of the user there is no email property at all. Neither in the root, or in the identities node.
Some root attributes provisioned through connections such as Social or Enterprise connections cannot be updated using the Management API. When trying to so do, you will most likely receive an error which states “operation not supported”.
The documentation states that when updating the properties for a secondary identity, meaning that the user has multiple identities created within the tenant, the connection parameter is required. However, that is not the case for the connections specified above whose root attributes are handled and provisioned by the IdP. In that case, they would need to be updated by the IdP.
As you have mentioned above, the update most likely fails when including both the email and name properties because the operation fails when trying to update the email. Otherwise, I would recommend going with the initial approach, where this information would be stored under user_metadata.