Feature:
Support for Identifier-First Authentication with Both Passwordless and Password-Based Logins in Universal Login
Description:
Currently, Universal Login does not support an Identifier-First flow that dynamically determines whether a user should authenticate via password or passwordless methods. Instead, it requires explicitly passing a connection parameter, which is impractical when users may belong to different authentication methods and their method is unknown beforehand.
The reason for this limitation, as noted in the documentation and discussions, is that Passwordless is inherently a sign-up-free authentication method. If Universal Login automatically switched between username-password and passwordless, it could create unintended new passwordless accounts when a user does not exist in the database, leading to duplicate accounts and security concerns.
However, many use cases require supporting both authentication methods within the same Universal Login experience. Possible solutions to address these concerns could include:
- Prioritization Logic in Universal Login
-
Similar to how Enterprise connections are prioritized over database authentication, allow configurable prioritization (e.g., Enterprise → Password → Passwordless).
-
If a user is not found in one connection, allow a controlled fallback to another authentication method without automatically creating a new account.
- User Prompt for Login Method
-
Introduce an option in Universal Login where users can explicitly choose between “Sign in with Password” or “Sign in with Code” if multiple methods exist for their identifier.
-
This avoids unintended account creation while allowing users to authenticate using their preferred method.
- Customizable Identifier-First Behavior
-
Provide an API or UI customization in Universal Login that allows developers to control what happens when an identifier is entered.
-
Instead of defaulting to creating a passwordless user when an email is not found, give developers control over whether to block login, suggest another method, or guide the user through a registration flow.
By implementing such improvements, Universal Login would support more flexible authentication flows while preventing security issues related to unintended account creation.
Use-case:
We are building an authentication system where users can log in using a combination of Enterprise SSO, username-password, and passwordless. Some users have multiple authentication methods associated with the same email (e.g., OIDC, traditional password login, and passwordless).
With the current Universal Login limitations, we must implement a custom identifier-first UI that determines the correct authentication method before redirecting the user to Auth0 with the appropriate connection parameter. This adds unnecessary complexity and makes it harder to maintain a seamless authentication experience.
If Universal Login could natively support identifier-first authentication that works across password and passwordless connections without the risk of unintended passwordless account creation, it would greatly simplify implementation and improve user experience.
We appreciate the security concerns behind this limitation, but introducing a configurable approach would allow developers to tailor the login experience to their specific needs.
Best regards,
José