User returned with wrong identity (not belonging to current Connection)

I have a setup where I have multiple Connections pointing to different custom databases. It seems like the users in one Connection is ignored. This is setup like this, because I have multiple environments, in this case: Staging and Production.

I fell over an issue when refreshing a token for some users. The user gets authenticated for the Production Connection, and gets the JWT (id_token, refresh_token, access_token). Then later when requesting a new JWT by using the refresh_token the returned id_token and access_token doesn’t belong to Production connection but the Staging connection.

This is also re-produceable in the Auth0 Dashbard. When I search for a user with the same username in both environments, two things happen. - On mouse over, the user details link is exactly the same for both Connections. - On the user details page, even when clicking the user for Production Connection, the User Details page shows that the users identity is Staging.

So my question is: is this intentional?

I thought that each Connection was separate and users could exist in both with different details attached to their profile.

Images attached as examples. (Second image is when clicked on the Production user)


There’s a few things worth mentioning here; the most important is that by default with regular database connections each user will receive a tenant/domain wide unique user identifier. However, with a custom database connection you (the custom database scripts) are responsible to ensure that the user identifier is unique across connections. A simple approach would be to use a unique prefix per each connection.

Based on what you describe it sounds like both users were using the same user identifier so the custom database connections did not meet the uniqueness requirement.

Finally, you mention you’re using separate connection in order to have a distinction between production and staging. Although connections give some degree of isolation between users, the recommended approach for having a development or staging environment would be to use a completely different tenant/domain; see more information about this at: Set Up Multiple Environments

Thanks @jmangelo - I was unaware of the uniqueness requirement. I’ll update my scripts with a prefix as you mentioned.