Authentication Patterns Overview

Authentication — proving who a user is — and authorization — deciding what they're allowed to do — are two of the most common requirements in a real application, and also two of the areas where Next.js deliberately stays out of your way.

Note

Next.js has no built-in authentication system. There is no next/auth module, no framework-level concept of a "logged-in user". Instead, the App Router gives you the primitives — cookies(), middleware, Server Actions, Route Handlers — that any auth approach is built on top of, and leaves the actual implementation (or the choice of library) to you.

The building blocks

Building block	What it answers
Session storage	Where does "this user is logged in" live between requests — a signed cookie, a database-backed session, a JWT?
Auth library / service	What handles credential verification, OAuth provider handshakes, and issuing sessions?
Route protection	What stops an unauthenticated request from reaching a protected page or API in the first place?

Every authentication setup, regardless of which library sits on top, ultimately answers those three questions. The differences between approaches are mostly about how much of each one is handled for you versus left for you to wire up.

Popular options

Auth.js (NextAuth) — the most widely used dedicated auth library for Next.js; handles OAuth providers, credentials, sessions, and Route Handler wiring. Covered in depth on the next page.
Clerk — a fully managed auth service with prebuilt UI components (sign-in, sign-up, user profile) and generous free tier; minimal code to get a polished flow running.
Supabase Auth — part of the Supabase platform; a good fit if you are already using Supabase as your database/backend.
Lucia — a lightweight, framework-agnostic session management library; less "batteries included" than the above, more control over the details.
Roll-your-own — cookies, a sessions table, and a password hashing library (e.g. bcrypt/argon2). Full control, full responsibility — every security decision (session expiry, CSRF, rate limiting) is yours to get right.

Tip

Unless authentication itself is the product, a managed solution (Clerk, Supabase Auth) or a mature library (Auth.js, Lucia) is almost always the better trade — the edge cases around session security, token refresh, and provider quirks are exactly the kind of thing that's cheap to get wrong and expensive to fix later. Rolling your own is a reasonable learning exercise, but rarely the fastest path to a secure production app.

The pages that follow work through the pieces in more detail: reading and setting cookies for sessions, how Auth.js structures a typical setup, and the different levels at which you can protect a route.

Next.js provides no built-in auth system — only the primitives (cookies, middleware, Server Actions) auth is built from.
Every approach answers the same three questions: where sessions live, what verifies credentials, and how routes get protected.
Auth.js, Clerk, Supabase Auth, and Lucia cover most real-world needs; rolling your own is possible but carries real security responsibility.
Managed/library solutions usually save more time and risk than they cost, outside of auth-as-the-product cases.