All Playbooks
Authenticationintermediate
Setting Up Authentication with Next.js
Authentication is the part of an app that has to be boring. This is the exact sequence I follow to bolt secure auth onto a Next.js project without inviting weird edge cases six months later. It covers provider choice, database design, session handling, route protection, and the small UI details that decide whether a login flow feels trustworthy or sketchy.
45 min7 steps
7
Steps
4
Tools
5
Outcomes
intermediate
Difficulty
Technologies used
Next.jsNextAuth.jsPostgreSQLPrisma
The methodology
The phases, in order
Each phase below is something I actually run in a project. The descriptions are how I think about the work, not abstract definitions.
01
Phase
Phase 1 of 7
Project Setup and Threat Model
Before any code, I write down what I am defending against. For most products it is account takeover, weak passwords, and session leakage, not nation-state attackers. Then I initialize a Next.js project with TypeScript and the App Router, install NextAuth, and add a strict TypeScript config so the auth layer fails loud during refactors. Pair this with my web development service if you want a head start on the surrounding scaffolding.
02
Phase
Phase 2 of 7
Database and Schema Design
I default to PostgreSQL with Prisma for user and session storage. The schema follows the NextAuth conventions but I always add columns for created_at, updated_at, last_seen_at, and a soft-delete flag from day one. Migrations get versioned in the repo, never run by hand. See Prisma vs Drizzle if you are picking an ORM and want my opinion on the tradeoffs.
03
Phase
Phase 3 of 7
NextAuth Configuration
I configure NextAuth with the database adapter, set session strategy to database for revocability, and wire up email plus OAuth providers. Callbacks are where I do the real work: customizing the JWT, attaching roles, and stamping the session with the user id. I keep the auth options file under 200 lines, and anything larger gets factored into helpers. The same patterns power the SaaS starter blueprint.
04
Phase
Phase 4 of 7
Middleware and Route Protection
Route protection lives in middleware so unauthenticated users never see protected layouts flash. I add per-route allowlists, role checks, and a redirect-to-login that preserves the original URL. Server actions and API routes get a separate auth guard helper so the rules are explicit at every call site. Cross-reference the API security playbook for token validation and rate limits.
05
Phase
Phase 5 of 7
Auth UI Components
Login, register, and verify pages get built with shadcn/ui primitives. I keep the forms accessible by default: real labels, proper aria attributes, and clear error states. The verify-email flow gets a polished resend button with a visible cooldown. Small details, but this is where users decide whether your product feels professional.
06
Phase
Phase 6 of 7
Session Management and Refresh
I implement session refresh on focus and a periodic ping while the tab is open. Sign-out clears the database session row, not just the cookie, so a stolen cookie cannot be replayed. I add an admin endpoint to revoke all sessions for a user, which has saved me twice in real incidents. See real-world implementations in my portfolio.
07
Phase
Phase 7 of 7
Audit and Production Checklist
Before shipping I run through a short checklist: HTTPS only, secure cookies, CSRF on mutating routes, password reset tokens that expire, rate limits on login and register, and audit logs for sign-in and password change. I also verify the OAuth redirect allowlist in each provider console. Nothing exotic, but skipping any one of these is how breaches happen.
Results
What You'll Achieve
Expected outcomes from implementing this playbook
Secure authentication with multiple providers across SaaS and e-commerce apps
Protected routes and API endpoints with explicit role checks
Revocable sessions and a clean sign-out story
User profile management with audit logging built in
Need help shipping this? Start a project or get in touch.
Use this playbook
Want me to run this with you?
The playbook is the public version. The private version is me running it for your team against a real deadline. If you have a project on the line, that is usually the faster path.
Related insights
More on this thinking
Related blueprints