Users with duplicate auth0 IDs

Help
,
1

We have an issue where there are multiple users with the same Auth0 ID.
For example, two users share this ID:
user auth0|5cad280a74e02a114ff02d9a, with a “portal-db” database connection
user auth0|5cad280a74e02a114ff02d9a, with an “impersonation” database connection

We don’t know how this happened, and we are ready to investigate, but first we need to resolve this somehow. It’s causing a lot of problems, including over a 100 users unable to access content our portal. Let me explain:

Because the IDs are supposed to be unique, all calls to all APIs (we’re mostly using Management API) target only one of the users. But if the user signs in as the other user with the same ID, we are unable to change their app_metadata, on which our latest feature relies. This also extends beyond the APIs. If we use Auth0’s Dashboard to try and update our users’s app_metadata, or anything else including e-mail verification status, the user’s name, or their user_metadata, it always gets saved only on one of the users. I presume it’s because they share IDs.

Desired outcome:
EITHER Impersonation users are linked to their non-impersonation same-ID counterparts
OR Impersonation users are deleted while their same-ID counterparts stay

Attempted solutions:
Deleting one of the users in Auth0 dashboard
outcome: Both users sharing the ID are deleted

Linking the two user account using Management API (/api/v2/users/PRIMARY_ID/identities)
outcome: 400 Bad Request “Main Identity and the new one are the same.”

Changing e-mail on one of the users
outcome: does not change auth0 ID and thus all Management API calls still target the newer Impersonation user

EDIT: Here’s a (modified) screenshot from our Auth0 Dashboard. It shows two users coming up in a search for user id auth0|5cad280a74e02a114ff02d9a

image
image859×457 40.3 KB

We opened a Support ticket #00466816 7 days ago. The issue has not yet been resolved and we haven’t heard back from anyone in that ticked since Thursday. We are anxious to get this resolved, because our customers are getting impatient and aggravated.

2

I’m afraid support work volumes can’t be fully planned ahead of time and there are always certain spikes in requests that may happen to coincide with less availability of resources and end up generating delays beyond what we would like.

I checked that ticket number just now and the ticket was re-assigned for more detailed review by our second tier of support and was picked earlier today. Based on the last update there’s a possible alternative offered through the Management API; my recommendation would be for you to review that approach and continue the discussion through the ticket.

1 Like
3

Thanks @jmangelo :smile:

I am going to mark this resolved, and we will let this process continue through the support ticket.

4

The alternative that was suggested by Support didn’t help in the end, but at last I realized what can help:

I want to delete all Impersonation connection users. I can achieve this by deleting the Impersonation database connection.

I did that, and the issue is gone. This solution is only applicable if your connection doesn’t hold any crucial data about the user.

As deleting the connection resolved our issue in the end, I’m marking this response as the solution.

2 Likes
5

Thanks for posting an update @peping

6

This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.