Skip to content
NuxtBase logo NuxtBase Docs

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

Section titled “What the Shipped Flow Looks Like”

Registration

Section titled “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:

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

Login

Section titled “Login”

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

Section titled “Protected Route Behavior”

NuxtBase protects these route families:

  • /dashboard
  • /admin
  • /ai

The route middleware does this:

  1. no session -> redirect to /login
  2. session exists but email not verified -> redirect to the verify-email confirmation page
  3. verified admin on auth pages -> redirect to /admin
  4. 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

Section titled “Password Reset Flow”

The shipped reset flow is:

  1. user opens /forgot-password
  2. user submits email
  3. app redirects to /auth/confirm?mode=reset-password&email=...
  4. reset email contains a Better Auth password-reset link
  5. user opens /reset-password
  6. user sets a new password
  7. 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.

Section titled “Magic Links”

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

The flow is simple:

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

The E2E suite covers this behavior as a first-class auth path.

Redirect Query Parameters

Section titled “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

Section titled “What To Test Before Customizing”
  1. register a new account
  2. verify the email arrives
  3. confirm unverified login redirects to /auth/confirm
  4. verify the email and reach the dashboard
  5. request a password reset and complete it
  6. test a magic-link sign-in