Hoe gaat u met authenticatie om in een Next.js App Router-app?

Question

Accepted Answer

Authenticatie in de App Router beslaat verschillende lagen — sessies, middleware, server-side checks en het beveiligen van Server Actions. De moderne benadering geeft de voorkeur aan **server-side sessieverificatie** boven client-only checks. ## Sessiestrategie ```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. Grove gating in middleware (snel, maar niet het hele verhaal) ```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(); } ``` Middleware loopt op de Edge voor elk overeenkomstig verzoek — ideaal voor goedkope redirects. Maar het mag alleen een *lichte* aanwezigheidscheck uitvoeren; vertrouw er niet op als de enige autorisatie (de cookie kan ongeldig zijn). ## 2. Verificatie van de sessie waar je de gegevens gebruikt (de echte poort) ```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}

; } ``` Deze server-side verificatie (in de Server Component) is de **gezaghebbende** check — deze valideert daadwerkelijk de sessie en laadt de gebruiker. ## 3. Bescherm ook Server Actions en 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 } }); } ``` Server Actions zijn openbare endpoints — **controleer altijd auth en autorisatie erin opnieuw**, ongeacht UI-level gating. ## Waarom gelaagde checks ```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 ``` ## Waarom het belangrijk is Auth in de App Router is verdediging in de diepte: httpOnly cookies (XSS-veilige sessies), middleware voor snelle redirects, en — cruciaal — **server-side verificatie op elk gegevensbereik en mutatiedeel**. De veel voorkomende, gevaarlijke fout is het behandelen van een middleware check of verborgen client UI als voldoende; echte bescherming komt voort uit het valideren van de sessie en autorisatie op de server waar gevoelige gegevens worden gelezen of gewijzigd.