Multiple connections with same email domain

We are currently using the Auth0 lock login screen and have several connections set up using different IDPs. We have leveraged Home Realm Discovery and assigned a domain name to each connection. Now when a user goes to the lock screen and enters their email the lock component will direct them to the correct IDP which all works great.

The problem we have is some of our clients have the same domain using different authentication techniques. Is there a way, given two or more connections to be configured with the same domain and lock login view to give the user an option to pick a connection? For example, two connections have for their domain, on the lock login the user types in, then the user is presented with an option to pick one of the two domains? I have tried setting two connections with the same domain but the lock client just takes the user to one of the IDPs.

1 Like

Hey Charlie,

I think your best bet would be to clear the “Email Domains” list in your connections settings. That should make the selection of connection a manual process. This link covers a few options for accomplishing this task.

That being said, we don’t currently recommend using the same Domain for two Auth0 Connections, if possible it’s best to use a separate Domain per Auth0 Connection.

Using the same domain for two connections can currently lead to a confusing Users listing in the dashboard depending on your connection type. In the situation where a user logs in to both domains, you would end up with one user record for each connection (as expected). But the links to view the user’s details could both pull up the same details for whichever user was created first. So you might click on User1/Connection2 and be taken to User1/Connection1 detail page.

The view from the Management API is better, but still a bit lacking. You can see all the users for a given email address by using the Get Users By Email endpoint. Again, even that does not expose their unique identifiers, but you will see a different identities array, logins_count, and various timestamps for each user.

This all has to do with how we currently create user_ids and admittedly is not ideal. We have an ongoing engineering effort to solve for this but unfortunately, I don’t have an ETA on when that project will be completed.

If you let me know specifically what type of connection your using I can dig in and see if you’d be affected by this issue.


Matt Maddex
Technical Support Engineer