I did as much research as I could regarding this topic.
As it looks like you cannot have both (Passwordless and Password and the Universal Login decides based on the identifier what to trigger). The question that arises here is why?
In my understanding the flow should be the following (using Identifier first):
User enters username / email or whatever
System detects that the entered identifier belongs to a passwordless user
Sends OTP
Universal Login asks for OTP
I’m aware that multiple users can share the same email. We have a funny case where a user has an OIDC, a username-password and a passwordless user using the same email.
In that particular case, Auth0 could simply either use their prioritization (first enterprise connection, then password, then passwordless) or better allow us to prioritize the connections.
Another solution would be to have a further button in the Universal Login that would ask the user if it wants to use passwordless.
While I’m also aware that we can pass a connection parameter to trigger password or passwordless we do not know beforehand what connection the user has.
The current solution seems the be having a custom UI built by us that asks for that identifier and we then determine what to do.
My questions here again:
Why is Universal Login not supporting this case?
What other solutions would be out there (apart from using the old Login Page and having a custom UI asking for the identifier e.g. email in our case)?
Welcome to the Auth0 Community and thank you for posting your question.
Firstly, I appreciate your insights on the matter, since the statements mentioned above are correct, as documented in our documentation about Selecting through multiple connections.
The reason why when using the Identifier first or Home Realm Discovery in the Universal Login you can not use both username-password and a passwordless connection is that unlike other connections the Passwordless one is by default sign-up free, meaning that the user does not necessarily need to a have a pre-defined account in order to sign in. Usually they can just input their email address, enter the one-time code and a new user is automatically registered.
The New Universal Login is considered to be the safest option when choosing your UI, so by switching dynamically between a passwordless and a password authentication , then if a user was not found in the username-password connection, it could unexpectedly create a new passwordless user. This can lead to unintended access issues, duplicated accounts or other security risks.
As for solutions regarding your use case, i believe you have already mentioned the only workaround, which involves creating a custom UI with backed up logic that checks for available authentication methods, while a brief example can be checked under our Lock configuration.
However, I also find this proposal very interesting, so I would encourage you to create a Product Feedback about this since it might receive multiple votes.
Thanks a lot for taking the time to answer my question in detail. It’s very much appreciated and I can understand the case fully now. Your answer helped us indeed to take the next implementation decision!
It makes sense now why. In our case, it would not hurt to allow both (Also since we have pre-registration action that checks the eligibility) but I understand that in other scenarios it might lead to undesired effects.
I will create a product feedback and in the meantime go with the custom UI solution.