Next.js Authentication

Authentication Building Blocks

Regardless of the specific library or strategy you choose, Next.js authentication generally involves the same building blocks: verifying credentials (a login form calling a Server Action or Route Handler), issuing some form of session identifier (a cookie, often containing a JWT or a reference to a server-side session), and checking that identifier on protected routes to allow or deny access.

The App Router's cookies() function (from next/headers) is central to most approaches — it's how Server Components, Route Handlers, and Server Actions read and write the cookie that identifies a logged-in user.

// A minimal login Server Action (illustrative, simplified)
"use server";
import { cookies } from "next/headers";

export async function login(formData: FormData) {
  const user = await verifyCredentials(
    formData.get("email") as string,
    formData.get("password") as string
  );

  cookies().set("session", user.sessionToken, { httpOnly: true });
}

This simplified example illustrates the core pattern: verify credentials, then set an httpOnly cookie identifying the session.

Common Authentication Approaches

1. Session cookies (server-tracked sessions, e.g. in a database)
2. JWTs (self-contained, signed tokens stored in a cookie)
3. Third-party auth providers (NextAuth.js / Auth.js, Clerk, Auth0)

• Session cookies require a server-side store (database, Redis) to look up session data.
• JWTs encode session data directly in a signed token, avoiding a server-side lookup on every request.
• NextAuth.js (now Auth.js) provides a full, batteries-included solution supporting both strategies.
• httpOnly cookies prevent client-side JavaScript from reading the session token directly, reducing XSS risk.

Authentication Approaches Cheat Sheet

Trade-offs between the main strategies.

Where Authentication Checks Happen

A complete authentication setup typically checks the user's session in more than one place: middleware for a fast, broad redirect of obviously unauthenticated visitors, and again inside the specific Server Component, Route Handler, or Server Action for a real, authoritative authorization check.

• Middleware: fast, cookie-presence check, mainly for UX redirects.
• Server Component / layout: authoritative check before rendering protected content.
• Route Handler / Server Action: authoritative check before performing a mutation.

Choosing an Approach for Your Project

For most real-world projects — especially anything supporting social logins (Google, GitHub) — NextAuth.js (Auth.js) is a reasonable default, since it handles OAuth flows, session management, and cookie security correctly out of the box. Rolling your own JWT-based system is more appropriate when you need full control or have unusual requirements a library doesn't support well.

Common Mistakes

• Storing a session token in a client-readable cookie instead of an httpOnly one.
• Relying only on middleware for authorization, skipping a real check inside the protected route itself.
• Rolling a custom JWT implementation without understanding token expiration and revocation trade-offs.
• Hardcoding secrets used for signing tokens directly in source code instead of environment variables.

Key Takeaways

• Next.js has no built-in auth system; you choose a strategy and often a library.
• Session cookies and JWTs are the two dominant low-level strategies.
• NextAuth.js (Auth.js) provides a full solution supporting both, plus OAuth providers.
• Authorization should be checked authoritatively in the protected route, not just in middleware.
• httpOnly cookies are important for reducing the risk of session token theft via XSS.