Authentication Methods

Configure email/password, magic link, and OAuth authentication methods in your SaaS application.

Choose how users sign in - email/password, passwordless magic links, or OAuth - by setting environment variables. No code changes required.

This page is part of the Authentication documentation.

The kit supports three authentication methods: email/password (enabled by default), magic links (disabled by default), and OAuth social providers (Google enabled by default). Toggle each method with environment variables. Password requirements (length, special characters, numbers, uppercase) are also configurable via environment variables, and the sign-in forms adapt automatically.

Authentication methods are the ways users prove their identity - credentials (email/password), passwordless (magic link), or delegated (OAuth via Google, GitHub, etc.).

  • Enable multiple methods when: you want to offer users flexibility. Many SaaS apps offer both OAuth and email/password.

If unsure: start with email/password and Google OAuth. Add magic links later if users request it.

Supported Methods

MethodDefaultEnvironment Variable
Email/PasswordEnabledNEXT_PUBLIC_AUTH_PASSWORD=true
Magic LinkDisabledNEXT_PUBLIC_AUTH_MAGIC_LINK=true
OAuth (Google)EnabledSee Social Providers

Email and Password Authentication

Enable or disable with:

apps/web/.env.local

NEXT_PUBLIC_AUTH_PASSWORD=true

Password Requirements

Configure password complexity rules:

apps/web/.env.local

NEXT_PUBLIC_PASSWORD_MIN_LENGTH=8
NEXT_PUBLIC_PASSWORD_MAX_LENGTH=99
NEXT_PUBLIC_PASSWORD_REQUIRE_SPECIAL_CHARS=true
NEXT_PUBLIC_PASSWORD_REQUIRE_NUMBERS=true
NEXT_PUBLIC_PASSWORD_REQUIRE_UPPERCASE=true

These settings enforce rules on both registration and password change forms. The UI displays requirements to users in real-time.

Email Verification

Email verification is required by default. Users must click a verification link before accessing the app. This prevents account takeover via email typos and confirms the user controls the email address.

Passwordless sign-in via email links:

apps/web/.env.local

NEXT_PUBLIC_AUTH_MAGIC_LINK=true

When enabled, users enter their email and receive a sign-in link. Clicking the link authenticates them without a password. Links expire after 10 minutes.

Requires email configuration: Magic links only work if your mailer is properly configured. See Email Configuration.

Common Pitfalls

  • Enabling magic links without email configuration: Links won't be delivered. Configure your mailer first.
  • Setting password requirements too strict: Users abandon registration. 8+ characters with one number is a reasonable minimum.
  • Disabling all auth methods: At least one method must be enabled or users can't sign in.
  • Forgetting email verification in production: Without verification, typos in email addresses create orphaned accounts.
  • Mixing environment variable formats: Use true or false (lowercase strings), not 1 or yes.

Frequently Asked Questions

Can I require MFA for all users?
MFA is opt-in per user by default. To require it for all users, you would need to customize the sign-in flow to check MFA status and redirect to setup. See the MFA Configuration documentation.
How do I disable email/password and only allow OAuth?
Set NEXT_PUBLIC_AUTH_PASSWORD=false and ensure at least one OAuth provider is configured. The sign-in form adapts to show only OAuth buttons.
Can users have both password and OAuth linked?
Yes. Better Auth supports account linking. A user who signed up with Google can later add a password, and vice versa.
Where are the sign-in forms?
Forms are in packages/auth/src/components/. They read environment variables to show/hide auth method options.
How do I customize the password reset flow?
The flow uses Better Auth built-in password reset with email verification. Customize the email template in packages/email-templates/src/emails/password-reset.email.tsx.

Next: Social Providers →