We’re configuring SSO between two Auth0 organizations—each with its own Auth0 database connection—but we need users in one organization to be able to log into the other. To make that work, each organization must enable the other’s database connection, so both organizations end up with two database connections. Auth0 defaults to the first connection in alphabetical order (or perhaps by the ID field in your database) when a user signs in, which isn’t ideal because the selected database connection might not contain the user that is logging in.
Today, the only way to override the alphabetically chosen database connection is to pass the connection parameter in the authorization request (which the auth0‑spa‑js SDK supports). That forces Auth0 to use our chosen database connection but hides every enabled enterprise connection on the Universal Login page.
What I’d like to see is a dedicated databaseConnection parameter—one that lets us specify which database connection to use for username/password logins without affecting the display or availability of enterprise connections on the Universal Login page.
I submitted this as a support ticket in the past and was told to create this Product Feedback request instead. Here are the options I was given to work around this issue, and my responses for each one:
-
Okta: “Since there is no out-of-the-box method to do this implementation. Using two database connections per organization is not recommended. Your implementation might work by creating a custom page where the user logs in. Then, you must send the authorization request with the connection and organization parameters to Auth0.
The desired connections need to be enabled for each organization in the dashboard under Organizations → Connections. This requires custom implementation on your side.”
My response: “Unfortunately, creating a custom login page on our end and specifying the connection and organization in the authorization request doesn’t scale either. If each organization has multiple enterprise connections, we must hardcode those for each site and add them to our login page. That leads to a poor user experience, because they’re choosing how to authenticate on our login page instead of on the Auth0 login page, and more complexity during development on our end, work that could be avoided with a slight change on your side.” -
Okta: “Another method is to have a single database connection. You can open a support ticket to merge users from two connections into one connection, which would take around 24 hours.”
My response: “That’s manageable once or twice, but we’re onboarding close to 200 organizations. Repeatedly submitting support tickets and merging users isn’t scalable, especially since new users can be added during that window, leading to gaps. It seems a lot easier to be able to choose the default database connection.” -
Okta: “This is a knowledge article that explains how databases work with organizations: Cannot Log In to Organization with Multiple Database Connections”
My response: "The documentation you linked to, stating that Auth0 defaults to ‘the first enabled database connection,’ appears to be incorrect. Unless I’m misunderstanding what the ‘first enabled database connection’ means, it doesn’t always choose the first enabled database connection that was added to an organization. If it did choose the first connection under an organization by default then I would be all set and everything would work as expected.