Next Auth Starter

The Problem

Authentication is one of the most frequently rebuilt things in web development — and one of the most dangerous to get wrong. Every new project needs login, registration, email verification, password reset, and ideally 2FA. Most developers either wire it up from scratch (slow and error-prone) or reach for a managed auth service (fast but adds a dependency and often a cost wall).

The gap is a well-structured starter that handles the hard parts correctly so you can clone it, configure it, and focus on the actual product.

The security-critical parts of auth — password hashing, session fixation, CSRF protection, rate limiting — are easy to implement wrong and hard to audit later. Getting them right once in a starter is worth more than getting them wrong twelve times across twelve projects.

What’s Included

Authentication methods:

• Email and password with bcrypt hashing and strength validation
• Google OAuth via NextAuth.js v5
• Magic links (passwordless email login)

Two-factor authentication:

• TOTP via otplib with QR code setup flow
• Backup codes for account recovery

Email system:

• Transactional emails built with React Email templates
• Welcome, verification, password reset, and login alert emails
• Delivered via Resend

Session and device management:

• Secure cookie-based sessions
• Device tracking — see all active sessions
• Per-device session revocation

Security hardening:

• CSRF protection on all mutation endpoints
• Rate limiting to block brute force attempts
• Zod validation on every input boundary
• Audit log of all authentication events

User management:

• Profile editing with avatar support
• Account deletion (GDPR-compliant)

Architecture

next-auth-starter/
├── app/
│   ├── api/          # Auth and user API routes
│   ├── auth/         # Login, register, verify, reset pages
│   └── profile/      # Session management, 2FA setup
├── emails/           # React Email templates
├── server/           # Server actions and auth utilities
├── schema/           # Zod validation schemas
└── prisma/           # Database schema + migrations

All authentication logic lives in server/ as Next.js Server Actions. The Zod schemas in schema/ are shared between client-side form validation and server-side enforcement, so the same rules apply at both layers.

Tech Stack

Quick Start

git clone https://github.com/akdevv/next-auth-starter.git
cd next-auth-starter
bun install
cp .env.example .env

Minimum required environment variables:

NEXT_PUBLIC_BASE_URL="http://localhost:3000"
AUTH_SECRET="your-secret-key"
DATABASE_URL="your-postgresql-url"
GOOGLE_CLIENT_ID="your-google-client-id"
GOOGLE_CLIENT_SECRET="your-google-client-secret"
NEXT_PUBLIC_RESEND_API_KEY="your-resend-api-key"

Then:

bun prisma generate
bun prisma db push
bun dev

Key Decisions

Why NextAuth.js v5 instead of a custom session layer? NextAuth handles the OAuth dance, CSRF tokens, and secure cookie attributes correctly out of the box. Writing that from scratch introduces too many opportunities for subtle security bugs. v5’s Server Actions integration makes it a natural fit for the App Router.

Why Resend + React Email instead of Nodemailer? React Email lets you build email templates with the same component model as the rest of the UI — testable, composable, and easy to preview locally. Resend has reliable deliverability without the SMTP configuration overhead. The combination produces professional transactional emails in much less code.

Why include 2FA in a starter? 2FA is often treated as an advanced feature to add later, but the database schema changes required (storing TOTP secrets, backup codes, verified state) are much easier to include from the start than to migrate in. A starter that omits it encourages skipping it permanently.

Why audit logging? Knowing when and from where users authenticate is useful for debugging and security investigations. The event log is a simple append-only table — cheap to write, high value when something goes wrong.

Outcome

A complete authentication system ready to drop into any Next.js project. The goal wasn’t to build another auth library — it was to build the thing you’d write yourself if you had the time to do it right, packaged so you don’t have to.