We’re currently using userID to link Auth0 and our DB but feels like it could be bad practice, because if an attack breaches the non-Auth0 DB then the attackers have a direct way to link user identity with the user data stored in our database and feels like it defeats the purpose of using a third-party service like Auth0.
A better way seems to have Auth0 generate a unique ID for each user and use that to link the two DBs and have the email stored in Auth0 only. If so, how do we retrieve that unique ID?
It could be the case that penetrating our DBWITHOUT a direct user-password interface is just as difficult as trying to attack Auth0’s DB WITH a direct user-password interface, but I don’t know enough about security to evaluate these two trade-offs.
It is common practice to use the Auth0 userID to access the users data in your non-auth0 DB. This is typically how it is done in my experience. UserID does not include email though. It should be
I have seen the email stored in this database for other purposes anyways, although I see what you are saying.
Regarding using a unique ID you generate…it would have to be stored in Auth0 somehow (in app metadata for example), defeating the purpose of another ID from my perspective. I would just stick with default userID.
Take a look at this doc where it is clearly stated: