I’m only guessing here , but if nameIdentifier is being set equal to the user’s root user_id attribute, that value is guaranteed to be unique within the given database, so it may be safe to use as a key into other databases, since you can always take those fields with you if you migrated to another solution.
That said, personally I would recommend implementing your own unique identifier. The example rule linked below would add a standard UUID to a user’s profile if they do not already have one. This is what I am pushing for where I work, though we haven’t implemented this yet. I just like the idea of using 1. an actual UUID standardized unique identifier and 2. something that is in no way linked to the underlying IAM service.
Thanks a lot for the explanation. It sounds like a lot fo the same thoughts I have had, I just wanted to make sure that it was the right approach.
The user_id attribute in Auth0 is in fact the id of the user, but with “auth|” put in front, which means it is very much tied into Auth0.
I will mark your comment as answer to end the question.
That’s correct. The root level user_id will have a prefix indicating what source system was used to create the profile. So auth0| for an Auth0 database user, google-apps| for a G Suite enterprise connection, google-oauth2| for Google social login etc.
You can take the user_id field with you if you leave Auth0 but personally I do prefer to have a plain industry standard UUID.