Universal Login Experience

Auth0 Universal Login provides the essential feature of an authorization server: the login flow. When a user needs to prove their identity to gain access to your application, you can redirect them to Universal Login and let Auth0 handle the authentication process.

The Universal Login experience offers a streamlined implementation with easy-to-use customization tools. For advanced customization, you can also create page templates that allow you to modify the code of your login pages. This experience also supports a variety of features, such as localization, WebAuthn, multi-factor authentication (MFA), Auth0 Organizations, and more.

Configuring Universal Login is dynamic and does not require any application-level changes, as web pages hosted on Auth0’s centralized authentication server drive the login flow. Additionally, you won’t need to manually update your code for your applications to benefit from improvements Auth0 makes to Universal Login.

The following sections provide additional details about the Universal Login experience. For a feature comparison between Universal Login and Classic Login, review Universal Login vs. Classic Login.

• You can specify a Liquid Template for all pages in the login flow with Page Templates.

• You can customize page branding, including colors, fonts, custom logo URLs, and more, with the no-code editor in the Auth0 Dashboard, or with the Management API Branding endpoints.

• You can configure the favicon URL with the Auth0 Management API Branding endpoints.

• You can customize page text with either the Auth0 Dashboard or the Management API. To learn more, review Customize Universal Login Text Elements.

• You can customize signup and login prompts with the Auth0 Management API. To learn more, review Customize Signup and Login prompts.

• You can use Passwordless with WebAuthn with Device Biometrics.

• If you are using development keys for social providers:

  • Single Sign-on (SSO) and Silent Authentication will work properly. This is not supported in the Classic Login experience.

  • Users receive a warning on the login page stating the tenant is configured with development keys.

• A button is rendered for each social and enterprise connection.

• If you redirect users to the /login page directly, they will receive an error unless you configured a default login route. To learn more, review Configure Default Login Routes. You should always redirect users to the proper authorization request endpoint (e.g., /authorize if you are using OpenID Connect).

• You can specify the login_hint when redirecting to Auth0 and use this information to populate the username/email field for the login or signup page.

• Passkeys are available as an authentication method for database connections. Passkeys are a phishing-resistant alternative to traditional authentication factors (such as username/password) that offer an easier and more secure login experience to users. To learn more, review Passkeys.

• You can have users land directly on the signup page instead of the login page by specifying the screen_hint=signup parameter when redirecting to /authorize. You can combine this paramter with prompt=login to indicate whether you want to always show the authentication page or skip the page if an existing session exists.

• If users have more than one MFA factor enrolled (e.g., SMS and push notifications), the Universal Login MFA page lets the user choose their preferred option.

• You can use voice or email as an MFA factor. To learn more, review Configure SMS and Voice Notifications for MFA and MFA Factors.

• If you are using the Guardian SDK to create your own native application to handle Push Notifications, you can configure the name of the application and the URLs to download them in the Push via Auth0 Guardian option in the Dashboard > Security > Multi-Factor Auth section.

• If you have a rule that sets the MFA provider to google-authenticator, you must enable that OTP factor in the Dashboard > Security > Multi-Factor Auth section.

• You can use WebAuthn for MFA.

• Using Actions, you customize your MFA flows to challenge users with a specific factor or series of factors. You can also leverage user metadata, such as roles or Organization memberships, to create more individualized experiences. To learn more, review Customize MFA Selection in Universal Login.

• The Universal Login experience redirects users to the default login route when it succeeds and handles the error cases as part of the Universal Login flow. The Redirect URL in the email template will be ignored. Note that you must provide an Application Login URI in the Dashboard > Applications > Applications Settings tab for the redirect URLs to work.

• If the database connection is set to Require Username, the password reset flow prompts the user for their username and sends a password reset email to the associated email address. To learn more, review Adding Username for Database Connections.

• Using Actions, you can incorporate a secondary challenge into your password reset flows. Specifically, the post-challenge trigger allows you to present an additional challenge to users after they complete their first step (typically a link in a password reset email) but before they create their new password. Using this trigger, you can redirect users to an external site, such as a third-party verifier, or challenge them with an additional MFA factor. Users must complete this second challenge in order to update their password.

  • Note: You can customize the MFA prompts displayed to users during the password reset flow. To learn more, review Customize Universal Login Text Prompts.

When using custom database connections:

• The password reset flow will function properly even if you return errors from the change password script.

• The errors returned in ValidationErrors or WrongUsernameOrPasswordError will be displayed on the corresponding pages. To learn more, review Troubleshoot Custom Databases.

After a user clicks the email verification link, they'll be redirected to a page that will confirm that their email is verified. If the default login route is configured, users will be able to click a button and get redirected to it.

Universal Login pages use the autocomplete attribute for password fields.

On the signup and password reset pages, autocomplete is set to "new-password". This signals the password manager to prompt the user to generate a secure, random password. The user has to provide explicit consent to save the password in the password manager.

On the login page autocomplete is set to "current-password". The login page automatically fills in the password if it's available in the browser's password manager.

Note that turning off password autocompletion does not increase security:

• Users need to opt-in for saving the password in the browser’s password manager

• Once it’s saved in the password manager, any user with access to the computer can go into the password manager and get the password whether the password is auto-filled on the login screen or not. If users are logged-in to the browser then they are prompted for their password before viewing saved passwords. If not, everyone can see them.

• In the case of Safari, users are asked to enter their Mac password or use Touch ID before the password is completed.

To learn how to set up your application to use Universal Login, read our Quickstarts. Choose the approach that best fits your technologies, and the Quickstarts walk you through the implementation.

• Configure Default Login Routes
• Configure SMS and Voice Notifications for MFA
• Multi-Factor Authentication Factors
• Check API Calls
• Check Login and Logout Issues
• Troubleshoot Multi-Factor Authentication Issues