We have a use case to ensure uniqueness around usernames and emails across multiple tenants.
Is there any, we can achieve this with auth0 dashboard?
Or I have to use pre registration action to make user search call across tenants and short circuit request in the action if user is found in other tenant?
If we go with action option, are there any downsides?
Will we be rate limited by search user call even though we are calling it via action?
How much latency overhead we can expect with this operation?
Reason we need uniqueness constraint for username/password is because we have single application. We will be having two tenants just to comply with GDPR.
Hi @kpritam
This is a complex question.
Ensuring uniqueness across multiple tenants is an anti-pattern.
Instead, I would start by architecting your platform to consider both email and region: your unique user identifier (key to a DB table) should be a combination of email and region.
As a aside, email is not recommended as a unique identifier - it is easy to have duplicate emails within a single tenant (with one DB connection and 1 social connection) and this can lead to account takeover vulnerabilities.
Also, look at the use case. Even though this is driven by GDPR, what is the use case for a user who is in the US but lives in the EU or a user who moves, etc.
John
2 Likes
We are not going to have social connections, so this should not be issue for us.
As I mentioned, we are going to have single application. We plan to have single login screen where user enters their username/email + password and expect server to determine which tenant this user belongs to. This enables us to not ask user to select country at the time of login. If we do not have this constraint, then server will not be able to determine which tenant to choose if username/email is present in both of the tenants.
Also other solutions like geo location based user discovery fails if user is on VPN or travels from their home country to other.
Hi @kpritam
I understand you are not going to have social connections now, but are you sure you will not want them next year? Two years? If you are using email as the DB key, and you decide in the future to add a social connection, you are inadvertently opening up a security hole.
For the use case you describe, I would recommend using an Auth0 custom DB connection (which is a set of scripts). The actual DBs would be hosted elsewhere - for the US DB you could host it as an Auth0 DB connection in the same tenant, and for the EU DB you could host in in an Auth0 DB connection in an EU tenant. (Beware of double logins, see below). Or you could host the DBs on your own in the appropriate region.
The login script would try both remote DBs and thus login and determine which region a user belongs to. It should be an error if both succeed.
Double Logins it is very convenient to use Auth0 DBs for the two regional DBs. But using this technique you will be charged 2 MAUs (monthly active users) for each login. That is because you get one MAU for the custom DB connection (with the script) and a second MAU for the regional DB.
1 Like
Hi @john.gateley , thank you for your detailed response.
I can see the downsides of making email address unique across tenants but routing to appropriate tenants is becoming tedious if we don’t have unique constraint.
Do you have any recommendation for routing requests to appropriate tenants in multi tenant applications?
I see this old unanswered question which explains this use case in detail: How to have one login page for multiple tenant regions?
Note that we are planning to use cloudflare proxy with custom domain.
The best recommendation I have is to engage our professional services team (Auth0 Professional Services).
This is a complex scenario, with MANY potential solutions, and also with severe pitfalls to choosing the wrong solution (like the email address enabling account takeover I mentioned above).
John