Come gestisci l'autenticazione in un'app Next.js con App Router?

Question

Accepted Answer

L'autenticazione in App Router si estende su più livelli: sessioni, middleware, controlli lato server e protezione delle Server Actions. L'approccio moderno favorisce la **verifica delle sessioni lato server** rispetto ai controlli solo lato client. ## Strategia di sessione ```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. Controllo coarse-grained nel middleware (veloce, ma non è l'intera storia) ```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(); } ``` Il middleware viene eseguito su Edge prima di ogni richiesta corrispondente — ideale per reindirizzamenti economici. Ma dovrebbe fare solo un controllo di *presenza leggero*; non fare affidamento su di esso come unica autorizzazione (il cookie potrebbe essere non valido). ## 2. Verifica la sessione dove usi i dati (il vero controllo) ```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}

; } ``` Questa verifica lato server (nel Server Component) è il controllo **autorevole** — in realtà convalida la sessione e carica l'utente. ## 3. Proteggi anche Server Actions e 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 } }); } ``` Le Server Actions sono endpoint pubblici — **sempre ri-controlla l'autenticazione e l'autorizzazione dentro di esse**, indipendentemente dal gating a livello UI. ## Perché i controlli stratificati ```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 ``` ## Perché è importante L'autenticazione in App Router è una difesa in profondità: cookie httpOnly (sessioni sicure da XSS), middleware per reindirizzamenti veloci, e — crucialmente — **verifica lato server a ogni punto di accesso ai dati e mutazione**. L'errore comune e pericoloso è trattare un controllo middleware o un'UI client nascosta come sufficiente; la vera protezione viene dalla convalida della sessione e dell'autorizzazione sul server ogni volta che i dati sensibili vengono letti o modificati.