Comment gérez-vous l'authentification dans une application Next.js App Router ?

Question

Accepted Answer

L'authentification dans l'App Router s'étend sur plusieurs couches — sessions, middleware, vérifications côté serveur et protection des Server Actions. L'approche moderne privilégie **la vérification de session côté serveur** aux vérifications uniquement côté client. ## Stratégie de session ```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. Vérification grossière dans le middleware (rapide, mais pas l'histoire complète) ```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(); } ``` Le middleware s'exécute sur l'Edge avant chaque requête correspondante — idéal pour les redirections peu coûteuses. Mais il doit faire seulement une vérification *légère* de présence ; ne comptez pas sur lui comme seule autorisation (le cookie pourrait être invalide). ## 2. Vérifiez la session où vous utilisez les données (la véritable porte) ```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}

; } ``` Cette vérification côté serveur (dans le Server Component) est la vérification **faisant autorité** — elle valide réellement la session et charge l'utilisateur. ## 3. Protégez aussi les Server Actions et les 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 } }); } ``` Les Server Actions sont des points de terminaison publics — **revérifiez toujours l'auth et l'autorisation à l'intérieur**, indépendamment de la vérification de l'interface utilisateur. ## Pourquoi les vérifications en couches ```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 ``` ## Pourquoi c'est important L'auth dans l'App Router est la défense en profondeur : les cookies httpOnly (sessions XSS-sûres), le middleware pour les redirections rapides, et — de manière cruciale — **la vérification côté serveur à chaque point d'accès aux données et de mutation**. L'erreur courante et dangereuse consiste à traiter une vérification middleware ou une interface utilisateur cachée comme suffisante ; la véritable protection vient de la validation de la session et de l'autorisation sur le serveur où que les données sensibles soient lues ou modifiées.