I have an application which has two database connections, both of which store their data in the Auth0 user store. Let’s call them connection-a and connection-b
If I request a password reset for a user in the connection-b database, it doesn’t work. In the log viewer I see this:
Type: Failed Change Password Request
Description: User does not exist.
Connection: connection-a
Application [application name and ID]
User [user’s email address]
It appears that the reset flow is only looking in one of our two connections for the user.
Using two database connections without specifying a particular one as parameter will always lead to problems and isn’t really a supported use case. May I ask: what is the context for using two databases? Based on which logic would users either be in one or the other connection?
And does your application allow signups? If so, how does the system decide which db connection to store the user in? See the related question (and comments) earlier this week:
I’ll throw in my use case, though it’s probably completely different than the OP’s.
I’m building a SaaS application and my intention was to have a separate connection per tenant. I would have a rule in place to convert connections to my internal organization IDs.
If I needed to turn a company off, I expected to be able to just disable the connection.
I wasn’t using signups or usernames. I expected that the companies I’m selling the SaaS to to all have emails from the same domain, even. The DB option was really intended for smaller customers that didn’t want to do a full back-end integration, or short term for larger customers during the integration phase.
That surprises me, given that the UI in applications/[app ID]/connections allows multiple database connections to be selected.
May I ask: what is the context for using two databases? Based on which logic would users either be in one or the other connection?
One database stores details of individuals employed by a client, the other stores details of individuals employed by us. We have one application that only the client has access to (hence, only their database is a connection for), and another application where both the client and some of our employees have access. For that application we use two connections, with the second connection database containing the internal employees who need access.
@s.whitaker Thanks for clarifying. I see your point, and definitely a valid use case (in most cases employees are in an AD/directory, therefore didn’t think of this one yet, but makes sense, absolutely).
So, in this case, if the email address domain of your employees is always clear, such as always being @yourcompany.com, then you could simply use this connection resolver:
(Note: this requires Lock = the Classic login widget, not the New Universal Login / ULP).
That surprises me, given that the UI in applications/[app ID]/connections allows multiple database connections to be selected.
It’s possible to select because it works fine if you specify the connection based on certain logic for the Lock widget.
allowedConnections: see docs
or defaultDatabaseConnection: see docs
or the mentioned ConnectionResolver above.
(But using these first two parameters isn’t applicable for your use case.)
So, let me know if above mentioned ConnectionResolver will work for you. If not, I see another solution, which is to federate the Auth0 tenant via custom SAML or OpenID Connect connection to itself. In this way, you can have regular username/password fields for end customers, and a button “Login with Employee Credentials” for employees.
It’s then even possible to detect which login to use based on your company’s domain and then offer the right button to the user once he enters a company email address and hide the email/password field for end users, which is called Home Realm Discovery
Do you get the idea? Might be a bit complex with just textual description - I can try to sketch this up later today or tomorrow. But maybe the first suggestion with the ConnectionResolver already works for you.
Yeah, we use a G Suite Enterprise connection for regular employee-only apps, but for this one we need only a specific subset of employees able to access the application.
We’re still on the classic login widget, so the link you sent looks good! I’ll take a look and let you know how I get on. Thanks!
OK, I can see that the connection resolver approach would work, but I’m loath to do it. We’d end up with code in our login page HTML at https://manage.auth0.com/dashboard/eu/[our org]/login_page that would be non-trivial and outside source control. I can see someone inadvertently breaking this in a few months’ time and leaving us completely in the dark.