The user identifier
user_id will be unique on each user identity (aka type of authentication; aka connection).
If an end-user, John Doe, authenticates with a database connection a user identifier will be assigned to that user identity, for example,
ID34. If the same end-user then perform a logout and proceeds to authenticate with a social provider another user identifier will be assigned to that user identity, lets say,
At this stage, for a single person, both Auth0 and your application will think that there two different users. We then support the concept of account linking which enables the same person to link multiple identities into a single user account and in this way be allowed to authenticate in multiple ways, but with the assurance that the application will see a normalized view of the user no matter the identity used to verify who the user is.
However, there’s multiple ways of implementing account linking and there will be considerations associated to each one. For example, if you implement account linking through a rule that automatically links user identities based on the same verified email then you’ll need to take in consideration that the user identity that initiated the transaction should be considered the primary and any existing user identity with the same email will be secondary. In this situation, you could say the user identifier for an existing user will change because the resulting linked user account will use the identifier associated with the primary identity and the primary identity is the one that just logged in for the first time.
If you want to use account linking and maintain absolute control on which user identity is treated as primary then I would not recommend using a rule to perform automatic account linking. Ideally this should be handled in your client application back-end; you could still use a rule that checks for other identities with the same verified email and includes a custom claim in the issued ID token. Your client application would then detect the custom claim and inform the user that they already authenticated using the same email and as such their identities will be linked (at this point you could control which one would be used as primary). Have in mind that you still need to decide on how you handle the user identifier situation; for example, you could force the user to authenticate again after having performed the linking and in this way the returned
sub would be the one associated with the primary identity you chose which would allow you to basically ensure that it would be the one that already has data associated with it in your client application.
In conclusion, if you make use of account linking then depending on how you perform it you may observe user identifier changes.