Hi, guys
I have two connections setup: one connection is a custom DB (connection A)
the other connection is a plain Auth0 connection (Connection B)
e.g.: First try to login with connection A , if failed try to login with connection B…until the user found.
When logging in a Auth0 with database connections, you need to be specific on which one you want to use. There’s no fallback to different connections.
If you are using Lock, the widget UI in the “classic” hosted login page, it will choose one of the connections, but there’s no defined behavior on which one will be chosen. Which is, as you can imagine, a very bad idea.
If you can decide which database connection to use based on the user’s email address, you can provide a connectionResolver option to Lock, which is Javascript code that will be used to select the connection (GitHub - auth0/lock: Auth0's signin solution).
What’s the logic behind having two different databases? Do you have different set of users in each of them? Is this a migration?
Thank you for the explanation.
Unfortunately, our users could have various email domains. So it seems that we can’t use the connection resolver in this situation.
Yes, I have completely different set of users, and it is not migration.
What I want to achieve is as below.
What’s the user flow for users that want to authenticate with an identity from application “B”?
To they go to application “B” and then get a link to your application? Or do they go directly to your application?
If your application is capable, by any mean (e.g. a query string parameter or a referrer header) of knowing where the user is coming, you could pass that information to the hosted login page as a parameter.
Then, in the hosted login page, you could use that parameter to specify the connection to be used by Lock (with the allowedConnections parameter).
If it’s not possible to know that in advance, another option is to present a UI in the hosted login page prior to displaying Lock, where you give users the choice (e.g. "click here to log in using the identity from app “B” or here to log in using the identity from app “A”).
Would any of these paths help?
They come directly to my application, so we can’t know them in advance.
If it possible, we want to authenticate with identities from A and B in just one universal login page.
(our client wants)
But technically, I understand that we should have UI to divide them before Lock which you suggested me.
Hi, I just come up with an idea.
Let’s say we have connection (A) with custom db setup and (B). Login requests will always go to connection (A) and handle authenticate with connection (B) too in the login script defined in connection (A).
Is that bad?
I would stay away from that kind of magic, mainly because it’s going to end up being confusing for users. For a user, it’s better to clarify what credentials you are supposed to use. Also for things like creating a user, verifying that the user exists already, the same user with identities in both places and different passwords, things could get really messy.
I would put a better-worded version of “Do you have an identity in application B? Click here to log in!” in your hosted login page, and let the user make that decision.
Also, consider what will happen when the user chooses to log in with their credentials from app B. Are you going to ask the user for credentials directly in your Auth0 domain? Even if it is a custom domain, it will look like “login.appA.com”. So any conscious user would be very wary of typing the credentials for App B in App A’s domain.
A better solution would be for App B to offer their own authentication service (they can use Auth0 or other idp that supports standard federation protocols), and you connect to App B’s federated identity provider via any of the standard enterprise connections in your Auth0 tenant (like OIDC or SAML). This way, when the user clicks on “I want to log in with App B’s identity”, there will be a redirection to App B’s identity provider to do the login.
Hopefully the above was not overly confusing, but it would be the proper alternative if App A and App B are not directly related, to avoid freaking users out.
Thank you for responding my trivial idea.
Finally, I decide to put button “Click here to log in” in the login page after hearing your opinion. My idea is too confusing as you pointed out.
Many thanks again for your support!
We’re here for you @kuma-guy!
This topic was automatically closed 15 days after the last reply. New replies are no longer allowed.
