Email & Password

For most buyers, this is the first auth flow to verify.

NuxtBase supports standard credential auth, but the shipped behavior is more opinionated than “email + password and you are in”. The template requires email verification before protected app access and uses confirmation pages to keep the flow clear.

What the Shipped Flow Looks Like

Registration

On /register, the user can create an account with:

full name
email
password
password confirmation

Key rules from the shared validation:

minimum password length: 8
maximum password length: 128
confirm password must match

After a successful registration:

the user is redirected to /auth/confirm?mode=verify-email&email=...
a verification email is sent
the user is not treated as fully signed in for protected app access until verification completes

On /login, a verified credential user signs in with email and password.

If the account is unverified, the template does not silently fail. It redirects the user to:

/auth/confirm?mode=verify-email&email=...

That behavior is tested in the template’s E2E suite and is part of the intended UX.

Protected Route Behavior

NuxtBase protects these route families:

/dashboard
/admin
/ai

The route middleware does this:

no session -> redirect to /login
session exists but email not verified -> redirect to the verify-email confirmation page
verified admin on auth pages -> redirect to /admin
verified non-admin on auth pages -> redirect to /dashboard

This means auth status is checked at navigation time, not only inside page components.

Password Reset Flow

The shipped reset flow is:

user opens /forgot-password
user submits email
app redirects to /auth/confirm?mode=reset-password&email=...
reset email contains a Better Auth password-reset link
user opens /reset-password
user sets a new password
app redirects back to /login

The reset page also has explicit states for:

missing token
invalid token
ready

That makes the flow easier to debug than a generic broken form.

Magic Links

Although this page is called “Email & Password”, the default login screen also supports magic links.

The flow is simple:

user enters email on /login
user clicks Send Magic Link
app emails a sign-in link
opening that link signs the user in and returns them to the app

Magic links work independently of password login. If password is disabled but magic links are enabled, the login page shows a standalone email input for the magic link flow.

Email OTP

The login page also supports email OTP sign-in. Users click “Sign in with Email Code”, enter their email in a modal, receive a 6-digit OTP, and enter it to complete sign-in.

Email OTP is a standalone login method and can be enabled or disabled independently of password or magic link.

Disabling Password or Passwordless Methods

All email-based auth methods can be toggled via NUXT_DISABLED_AUTH_METHODS. When password is disabled:

the registration form, password login form, forgot-password, and reset-password pages become inaccessible
the password section in dashboard settings is hidden
magic links and email OTP can still work independently if enabled

See setup/authentication-setup for configuration details.

Redirect Query Parameters

The login page supports a safe redirect query parameter, for example:

/login?redirect=/dashboard/projects

After successful login, the user is sent to the requested internal path.

The implementation only accepts safe app-relative paths, which protects against open redirect issues.

What To Test Before Customizing

register a new account
verify the email arrives
confirm unverified login redirects to /auth/confirm
verify the email and reach the dashboard
request a password reset and complete it
test a magic-link sign-in