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?
Hi @jonathan.hughes,
Indeed, also not providing the org_id in the initial request makes this case a bit more complicated. However, as specified in this article as well - Enabling Multiple Database Connections for a Single Application, it is mandatory to pass a “connection” parameter to the /authorize request and when initiating the password reset flow via the POST request to the dbconnections/change_password endpoint when using multiple databases, this being the only challenge in this scenario.
If your users share different domains and you aren’t using the Organizations prompt, Auth0 has no mathematical way to know which database a user belongs to until they are logged in. To fix this, your application must perform a User Lookup via the Management API using the email address in order to retrieve a user’s connection. Once you identify it, you pass that name into the login/reset request. This resolves the ‘User Not Found’ error because you are telling Auth0 exactly which database to search.
A possible The Workflow would be:
- In your app’s UI, instead of sending the user straight to Auth0, you have a simple “Enter your email” screen on your own site.
- When the user hits “Next,” your backend calls the Auth0 Management API:
GET /api/v2/users-by-email?email=user@gmail.com
- The Identification: The API returns an array. You look at the
identities[0].connection field to see if they belong to User-DB-1, or User-DB-2.
- Now that your app knows the connection, you trigger the Auth0 Login (or Reset) and explicitly pass that connection name.
I understand this would not be an out of the box solution, but it should allow you to implement your use case regardless of users’ affiliated email domains.
Hope this helps!
Best regards,
Remus
I’d offer a counterpoint: there’s an article that appears to acknowledge this as a bug in Auth0’s implementation. Rather than addressing it, the issue seems to have been deferred to customers, requiring workarounds for Universal Login’s inability to properly handle an otherwise supported authentication architecture. As a result, I’ll likely move to a single user database.
For what it’s worth, this behavior only seems to affect applications with multiple username/password databases. External enterprise connections configured on the same application do not appear to have any issues authenticating concurrently.
Hi @jonathan.hughes,
Your observation that external enterprise connections work seamlessly while multiple database connections do not is consistent with how Auth0’s Home Realm Discovery (HRD) functions. Enterprise connections have unique email domains that allow for automatic “discovery,” whereas multiple database connections sharing a domain (or having none specified) require manual “hints” via a connection or organization parameter to function properly.
In this scenario, as you have mentioned as well, the most straight forward way of achieving this would be to use only one database connection per application/organization, as this is currently the recommended option from our side.
This is not considered to be a bug from our end, however there is also no out of the box solution at the moment, so I would highly encourage you to upvote this Feature Request - Choose a default Database Connection during an authorization request without affecting enterprise connections and leave a reply if there would be anything else to be added. This requests are closely monitored by our Product Team and a higher number of votes can lead to future implementation on our end.
Thank you!
Remus
While I respectfully disagree on the opinion that this is not seen as a bug, it is at the end of the day, a limitation to support a login flow that the Auth0 infrastructure allows you to design. If the Auth0 infrastructure allows a configuration to be build that then is blocked by its own login page, then that to me, points to the idea that that is a flaw, or bug in the login process.
If the Login Experience is set to Prompt for credentials, the first field is email, which if a user had multiple organizations, should then be getting prompted for which organization to login. If you have to give a hint in this setup to which organization, then that is a totally broken workflow.
I do not see a way to add domains to a user-pw database so I don’t see how that provides a solution or issue in the context of this problem.
I had already submitted feedback on supporting this but have additionally added my vote to that specific feature linked. Although with as little upvotes and almost a year since that post was made, I have very little hope it’ll ever be addressed.