¿Cómo se maneja la autenticación en una aplicación Next.js App Router?

Question

Accepted Answer

La autenticación en el App Router abarca varias capas — sesiones, middleware, verificaciones del lado del servidor y protección de Server Actions. El enfoque moderno favorece **la verificación de sesiones del lado del servidor** sobre las verificaciones solo del cliente. ## Estrategia de sesión ```text Cookie-based sessions (httpOnly cookie): ✓ Store a signed session id or encrypted JWT in an httpOnly, secure cookie ✓ httpOnly = not readable by JavaScript → protects against XSS token theft ✓ Use a library: Auth.js (NextAuth), Clerk, Lucia, or a custom solution ``` ## 1. Control grueso en middleware (rápido, pero no es toda la historia) ```ts // middleware.ts — quick check: does a session cookie exist? export function middleware(req: NextRequest) { const session = req.cookies.get("session")?.value; if (req.nextUrl.pathname.startsWith("/dashboard") && !session) { return NextResponse.redirect(new URL("/login", req.url)); } return NextResponse.next(); } ``` El middleware se ejecuta en el Edge antes de cada solicitud coincidente — ideal para redirecciones económicas. Pero solo debe hacer una verificación de presencia *ligera*; no confíes en él como la única autorización (la cookie podría ser inválida). ## 2. Verifica la sesión donde usas los datos (la puerta real) ```tsx // app/dashboard/page.tsx — verify on the server, in the page itself import { redirect } from "next/navigation"; export default async function Dashboard() { const user = await getCurrentUser(); // validates the session cookie server-side if (!user) redirect("/login"); // authoritative check return

Welcome {user.name}

; } ``` Esta verificación del lado del servidor (en el Server Component) es la comprobación **definitiva** — realmente valida la sesión y carga el usuario. ## 3. Protege también los Server Actions y Route Handlers ```tsx "use server"; export async function deletePost(id: string) { const user = await getCurrentUser(); if (!user) throw new Error("Unauthorized"); // never trust the caller if (post.authorId !== user.id) throw new Error("Forbidden"); // authorization await db.post.delete({ where: { id } }); } ``` Los Server Actions son endpoints públicos — **siempre vuelve a verificar auth y autorización dentro de ellos**, sin importar el control a nivel de UI. ## Por qué controles en capas ```text Middleware → fast redirect for the common case (better UX, not security-critical) Server Component/Action → real verification (security boundary) Never rely on hiding UI in the client as a security measure ``` ## Por qué es importante La autenticación en el App Router es defensa en profundidad: cookies httpOnly (sesiones seguras contra XSS), middleware para redirecciones rápidas y — críticamente — **verificación del lado del servidor en cada punto de acceso a datos y mutación**. El error común y peligroso es tratar una verificación de middleware o una UI cliente oculta como suficiente; la verdadera protección proviene de validar la sesión y autorización en el servidor dondequiera que se lean o cambien datos sensibles.