L'authentification dans une app Next.js

L'auth, c'est là qu'on se plante le plus, et où ça coûte le plus cher. Sessions ou JWT, où stocker le token, où placer les vérifications : voici le socle d'authentification que je monte, simple et solide.

StackNext.jssessionsJWTcookiesOAuthmiddleware

Sessions vs JWT

Deux façons de se souvenir qu'un utilisateur est connecté. Le débat est éternel ; en pratique, le choix est simple pour un SaaS classique.

session (serveur)

révocable.

·l'état vit en base / Redis

·déconnexion immédiate possible

·idéal pour un SaaS

JWT (stateless)

scalable.

·aucun stockage côté serveur

·dur à révoquer avant expiration

·bien pour du service-à-service

À retenir

Par défaut, pour un SaaS, je prends des sessions : pouvoir déconnecter un utilisateur immédiatement vaut mieux que l'élégance stateless du JWT.

Où vérifier

Le middleware protège des groupes de routes d'un coup (redirection si pas de session). Mais il ne remplace pas la vérification dans chaque API route : le middleware garde la porte, la route garde le coffre.

middleware.tsTSCopier

// middleware.ts — protege un groupe de routes d'un coup
import { NextResponse } from "next/server";
export function middleware(req) {
  const session = req.cookies.get("session");
  if (!session) return NextResponse.redirect(new URL("/login", req.url));
  return NextResponse.next();
}
export const config = { matcher: ["/dashboard/:path*", "/settings/:path*"] };

Attention

Ne te repose jamais sur le seul middleware pour la sécurité des données : chaque route doit re-vérifier session ET propriété de la ressource. C'est la faille IDOR de les failles de sécurité de base.

OAuth & le reste

·pour « se connecter avec Google/GitHub », une lib éprouvée (Auth.js) plutôt que rouler le tien ;

·hash des mots de passe avec bcrypt/argon2 — jamais en clair, jamais un hash rapide ;

·rate limiting sur le login pour bloquer le brute-force ;

·expiration + rotation des sessions, et déconnexion qui invalide vraiment côté serveur.

À retenir

Le rate limiting du login a son propre article : rate limiting et protection d'API.

Sources & ressources

01Next.js — How to implement authentication in Next.jsLa doc officielle : sessions stateless vs base, options de cookie recommandées, et pourquoi les vérifications vivent dans une Data Access Layer plutôt que dans le seul middleware.↗02Auth.js — Session strategiesLe compromis JWT vs session en base vu par Auth.js : révocation, « sign out everywhere », limite des ~4096 octets d'un cookie.↗03OWASP — Session Management Cheat SheetLa référence sur les attributs de cookie (HttpOnly, Secure, SameSite) et sur la régénération de l'ID de session à chaque changement de privilège.↗04OWASP — Cross-Site Request Forgery Prevention Cheat SheetPourquoi SameSite=Lax ne suffit pas tout seul, et quand ajouter un synchronizer token ou un double-submit signé.↗05MDN — Using HTTP cookiesLa définition exacte de chaque attribut posé dans le code plus haut : HttpOnly, Secure, SameSite, Max-Age, Path.↗06OWASP — Password Storage Cheat SheetArgon2id en premier choix, bcrypt (work factor ≥ 10) pour les systèmes existants — de quoi calibrer le hash des mots de passe.↗07RFC 9700 — Best Current Practice for OAuth 2.0 SecurityLe socle OAuth moderne : PKCE obligatoire pour les clients publics, redirect URIs exactes — ce que les bonnes libs font déjà pour toi.↗

En résumé

Une auth solide n'est pas compliquée, elle est rigoureuse : sessions révocables pour un SaaS, token dans un cookie httpOnly, vérification dans chaque route et pas seulement au middleware, mots de passe hachés. Ne réinvente pas la roue sur OAuth — mais comprends chaque pièce.

Auth.js docs ↗