Wie handhabst du Authentifizierung in einer Next.js App Router-App?

Question

Accepted Answer

Authentifizierung im App Router erstreckt sich über mehrere Schichten — Sessions, Middleware, serverseitige Überprüfungen und der Schutz von Server Actions. Der moderne Ansatz bevorzugt **serverseitige Session-Verifizierung** gegenüber ausschließlich clientseitigen Überprüfungen. ## Session-Strategie ```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. Grobe Kontrolle in Middleware (schnell, aber nicht die ganze Geschichte) ```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 läuft am Edge vor jedem abgestimmten Request — ideal für kostengünstige Umleitungen. Sie sollte aber nur eine *leichte* Präsenzüberprüfung durchführen; verlasse dich nicht darauf als alleinige Autorisierung (das Cookie könnte ungültig sein). ## 2. Verifiziere die Session dort, wo du die Daten nutzt (das echte Tor) ```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}

; } ``` Diese serverseitige Verifizierung (in der Server Component) ist die **maßgebliche** Überprüfung — sie validiert tatsächlich die Session und lädt den Benutzer. ## 3. Schütze auch Server Actions und 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 sind öffentliche Endpoints — **überprüfe Auth und Autorisierung immer erneut darin**, unabhängig von UI-Gating. ## Warum mehrschichtige Überprüfungen ```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 ``` ## Warum es wichtig ist Auth im App Router ist Verteidigungstiefe: httpOnly Cookies (XSS-sichere Sessions), Middleware für schnelle Umleitungen, und — entscheidend — **serverseitige Verifizierung an jedem Datenzugriffs- und Mutationspunkt**. Der häufige, gefährliche Fehler ist, eine Middleware-Überprüfung oder versteckte Client-UI als ausreichend zu behandeln; echter Schutz kommt von der Validierung der Session und Autorisierung auf dem Server überall dort, wo sensitive Daten gelesen oder geändert werden.