I have an application that has 3 connections for access. Each connection is enabled on its own organization. The first 2 worked fine, one was an enterprise connection and one a user-db. I added the third connection, another user-db but when the users try to reset their passwords on this new connection, it says the user does not exist and is looking at the first user-db.
The password can’t be reset because the user does not exist in the first user-db, which is obvious, because the user is in the other user-db but Auth0 doesn’t seem to check all databases, just fails on the first one and users on the second db can’t login.
Hello @jonathan.hughes,
Welcome back to the Auth0 Community!
Please allow me some time to investigate this issue further and I will be back with a response as soon as possible.
Thank you for your understanding!
Best regards,
Remus
Thanks for looking into this. Hoping there’s a solution for this configuration soon, otherwise, I will need to start restructuring my setup to work around the issue.
Hi @jonathan.hughes,
I am sorry for replying late to your inquiry!
What I would recommend is to trigger the password reset flow for users who are part of the second database connection using the Authentication API by making a POST request to the /dbconnections/change_password endpoint and append the “connection”: “Your-Connection” parameter to the request since your app needs to know which organization/connection the user belongs to before sending the reset email, so that it will not default to the first database, which is the recommended Alternative Self-Service Password Reset Option for Database Connection Users .You can also check out our Change Users’ Passwords documentation.
Other recommendations in this case would be to ensure that Identifier First is enabled in your Authentication Profile settings so that Auth0 looks up that email across your connections to discover which database they belong to. Also please make sure that no Default Directory is set up under your General Tenant Settings. If this field is completed with the name of one of your databases, Auth0 will always default to it.
Please let me know if this helps and if you have further questions as well!
Thank you,
Remus
I confirmed there is no default Default Directory set and changed from Idenity and Password to just Identity with no change in behavior. If there is a self-service option to reset the password from the universal login that does not work, then this points to an identifiable bug in the login flow.
Let’s say I go through this user database, manually reset every single user by defining the database connection in the API. Now the users have valid emails, which they likely already have that they setup when they verified their email/account. Now what? Auth0 still won’t recognize their login on the appropriate database, it will still look at database 1, say don’t know who this user is, and fail, never looking at database 2.
Two databases are on an App, Auth0 fails to check all databases and fails any login flow. This sure seems like a bug in the underlying login flow for this configuration.
Hi @jonathan.hughes,
I understand why this might seem as a bug from your perspective, and indeed, just selecting the Identifier first as Authentication profile is not enough in this case, as Auth0 does not perform a “global search” across all databases when a user just types in their email, this being for account enumeration purposes, since like this anyone could intercept if an email address is listed under a specific database and since Auth0 is designed to be “Tenant Isolated” ( meaning the general approach would be having a different database of users for each tenant ). This is why it is mandatory that a connection parameter should be used in this case.
Since these connections are tied with your Organizations, the application should already know the org_id and the connection that the user is using based on that, so you should pass both the org_id and the connection parameter when making a call to the /dbconnections/change_password endpoint, alongside the client_id.
Additionally, your /authorize call also needs to include the same parameters, such as:
- organization: “org_abcd”,
- connection: “db_connection2”
So now Auth0 knows to only check the connection enabled for that specific Organization even when pressing on the Forgot password link. Password resets will work instantly because Auth0 is only looking at Database B. I believe this should be the best option.
This article - Configuration Guidance for the Password Reset Flow Using the Change Password Email (Link) provides documentation that should come in handy.
I hope this help your use case!
Thank you,
Remus
I’d like to push back a bit on the idea that this isn’t a bug. The application login is configured to Prompt for Credentials, which—based on how the flow designation works—should allow a user to authenticate without an organization being specified up front, since a user may legitimately belong to multiple organizations.
Because of that, the ability to search across all available database connections within the application is a necessary requirement for this flow to function correctly. The “global search” mentioned earlier doesn’t really apply here, as this isn’t a global scope—it’s limited to the databases associated with a specific application and tenant.
@remus.ivan Any additional thoughts on this topic? Do I need to abandon the idea that Auth0 can handle multiple user-password databases on a multi-org, single application configuration?