New Universal Login Experience

Auth0's New Universal Login Experience provides a reimagined login flow, with a fresh UX design and lightweight pages. When you pick this new experience, Auth0 will use it for all pages that haven't been customized. You can enable it in the Dashboard the Branding > Universal Login Settings tab.

The key structural difference from the Classic Experience is that the former uses Javascript widgets in all the pages, while the New Experience is rendered on the server and does not require Javascript.

From a functional perspective, the New Experience has much better support for Localization, WebAuthn support, a better MFA experience, support for Organizations, and several improvements across all pages.

The New Experience is being actively developed, so we add new features regularly. Some pages in the New Experience have certain differences detailed below. To see a feature comparison, read New Universal Login vs. Classic Universal Login.

Customize login flow

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

  • You can configure the custom logo URL in the Auth0 Dashboard with the No-Code Editor or with the Auth0 Management API Branding endpoints.

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

  • You can customize text prompts in the Auth0 Dashboard or with the Auth0 Management API. To learn more, read Customize New Universal Login Text Prompts.

How it is different from Classic Universal Login

Login

  • 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, which does not happen in the Classic Experience.

    • Users will see a warning on the login page mentioning that the tenant is configured with Development Keys. To learn more, read Development Keys.

  • A button will be rendered for each social and enterprise connection.

  • If you redirect users to the /login page directly, they will get an error unless you have configured the default login route. To learn more, read 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 it will be used 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, read Passkeys.

Signup

  • You can make users land directly on the Signup page instead of the Login page by specifying the screen_hint=signup parameter when redirecting to /authorize. Note that this can be combined with prompt=login, which indicates whether you want to always show the authentication page or you want to skip if there's an existing session.

/authorize parameters No existing session Existing session
no extra parameters Shows the login page Redirects to the callback url
screen_hint=signup Shows the signup page Redirects to the callback url
prompt=login Shows the login page Shows the login page
prompt=login&screen_hint=signup Shows the signup page Shows the signup page

Multi-factor authentication

  • If users have more than one multi-factor authentication (MFA) factor enrolled (e.g., SMS and Push notifications), the new MFA page will let the user select which one they want to use.

  • You can use voice or email as an MFA factor. To learn more, read 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 need to enable the 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 New Universal Login.

Password reset

  • In the Classic Login Experience, you can configure a URL to redirect users after completing the password reset. The URL will receive a success indicator and a message. The New Universal Login Experience redirects users to the default login route when it succeeds and will handle the error cases as part of the Universal Login flow. The Redirect URL in the email template will be ignored. Please 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 will ask the user for the username and send a password reset email to the associated email address. To learn more, read 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.

Custom database connections

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, read Troubleshoot Custom Databases.

Email verification

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.

Password autocomplete

For New Universal Login pages, password fields use the autocomplete attribute.

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.

Implement Universal Login using Quickstarts

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.

Learn more