Authentification Next.js : Auth.js, Better Auth ou Clerk | We.Inc
Comparez Auth.js, Better Auth, Clerk, Supabase Auth et une session codée à la main pour Next.js 16, avec le code de mise en place de chacun et un sélecteur qui réduit la liste selon vos besoins.
Authentification Next.js : les options comparées
Pour la plupart des applications Next.js, choisissez une bibliothèque plutôt que d'écrire l'authentification vous-même. Clerk est hébergé et le plus rapide à mettre en place, Supabase Auth convient aux applications déjà sur Supabase, et Better Auth ou Auth.js gardent les utilisateurs dans votre propre base de données. Quel que soit votre choix, revérifiez la session dans le code serveur, car les vérifications dans le proxy ne suffisent pas à protéger les données.
En un coup d'œil
Option
Stockage des utilisateurs
Clerk
Les serveurs de Clerk
@clerk/nextjs, ClerkProvider, clerkMiddleware dans proxy.ts
Supabase Auth
Votre projet Supabase
clients @supabase/ssr plus un proxy qui rafraîchit la session
Better Auth
Votre propre base de données
instance auth plus app/api/auth/[...all]/route.ts
Auth.js (next-auth v5 bêta)
Votre base de données ou un cookie JWT
auth.ts plus app/api/auth/[...nextauth]/route.ts
Solution maison
Votre propre base de données
jose ou iron-session, cookies httpOnly, une couche d'accès aux données
Le guide officiel de Next.js liste douze bibliothèques d'authentification compatibles, soit plus de choix que la plupart des gens n'en veulent. Cette comparaison se limite aux cinq voies que la plupart des équipes envisagent vraiment, montre le code minimum de chacune avec l'App Router et explique les vérifications que vous devez toujours à votre application, quelle que soit la bibliothèque qui connecte les utilisateurs.
Cochez les exigences qui comptent pour vous, comme garder les données des utilisateurs dans votre propre base ou disposer d'écrans de connexion prêts à l'emploi.
Le sélecteur masque les options qui ne remplissent pas toutes les exigences cochées.
Ouvrez le code de mise en place des options restantes et comparez la quantité de code à écrire.
Lisez la section sécurité avant de mettre en production, quelle que soit l'option choisie.
Stockez les sessions dans des cookies définis côté serveur avec HttpOnly, Secure, SameSite et une date d'expiration, comme le recommande le guide Next.js.
Placez une fonction verifySession() dans un seul fichier réservé au serveur et appelez-la depuis les pages, les Server Actions et les Route Handlers.
Ne comptez pas sur un layout pour les vérifications d'authentification. Les layouts ne se réaffichent pas lors de la navigation côté client, la vérification peut donc être sautée.
Gardez le contenu de la session léger : un identifiant d'utilisateur et un rôle, jamais une adresse e-mail ni un numéro de téléphone.
Générez les secrets avec openssl rand -base64 32 (ou npx auth secret pour Auth.js) et gardez-les dans des variables d'environnement.
Questions fréquentes
NextAuth est-il toujours maintenu ?
Auth.js, le projet autrefois appelé NextAuth, indique sur son propre site qu'il fait désormais partie de Better Auth. Sa commande d'installation pour Next.js reste npm install next-auth@beta. Les nouveaux projets démarrent souvent directement sur Better Auth, tandis que les applications Auth.js existantes continuent de fonctionner.
Puis-je protéger des pages avec proxy.ts seul ?
Non. La documentation de Next.js qualifie les vérifications du proxy d'optimistes : utiles pour des redirections rapides basées sur un cookie, mais pas une barrière de sécurité. Revérifiez la session au plus près des données, car les Server Functions et les routes hors du matcher ne passent jamais par le proxy.
Quelle option coûte le moins cher ?
Les bibliothèques qui stockent les utilisateurs dans votre propre base de données, comme Better Auth ou Auth.js, n'ont aucun frais par utilisateur ; vous payez votre base de données et l'envoi des e-mails. Supabase Auth inclut 50,000 utilisateurs actifs mensuels dans l'offre gratuite en octobre 2026. Consultez la page de tarifs de Clerk pour son quota gratuit actuel.
Fonctionnent-elles avec Next.js 16 ?
Oui. Clerk et Supabase documentent tous deux proxy.ts pour Next.js 16 et middleware.ts pour les versions plus anciennes, et Better Auth fournit un utilitaire de cookie pour le proxy ainsi qu'une vérification complète de session pour le code serveur.
Sessions sans état ou en base de données ?
Un cookie signé (sans état) est plus simple et ne demande aucune recherche, mais vous ne pouvez pas le révoquer avant son expiration. Une session en base coûte une requête par vérification et permet aux utilisateurs de se déconnecter de tous leurs appareils. De nombreuses bibliothèques vous laissent choisir.
Hébergé ou auto-hébergé
Clerk gère pour vous la base d'utilisateurs, les pages de connexion et les sessions, et vous placez ses composants dans votre layout. Vous échangez un peu de contrôle et une facture mensuelle à grande échelle contre de la rapidité et une interface soignée dès le premier jour.
Better Auth et Auth.js tournent dans votre application et écrivent dans votre base de données. Les données et les écrans vous appartiennent, mais l'envoi des e-mails, les parcours de réinitialisation du mot de passe et les mises à jour aussi.
Si vous utilisez déjà Supabase
Supabase Auth relie directement la connexion à la sécurité au niveau des lignes de Postgres, si bien qu'une politique comme auth.uid() = user_id protège les données au niveau de la base. Le paquet @supabase/ssr stocke la session dans des cookies pour que les Server Components puissent la lire.
La documentation de Supabase prévient que getSession() renvoie des données non vérifiées. Utilisez getClaims(), qui vérifie la signature du jeton, ou getUser(), qui interroge le serveur d'authentification, avant de vous fier à l'identité de l'utilisateur.
Écrire la vôtre
Le guide Next.js la décrit pas à pas avec une Server Action pour le formulaire, Zod pour la validation, bcrypt pour le hachage et jose pour signer un cookie de session valable sept jours. C'est un bon moyen de comprendre tous les rouages.
Pour la production, ce même guide recommande une bibliothèque, car la limitation de débit, la vérification des e-mails, la liaison de comptes et la connexion multifacteur s'additionnent vite.
Mise en place minimale pour chaque option
Clerk
Installez @clerk/nextjs et définissez NEXT_PUBLIC_CLERK_PUBLISHABLE_KEY et CLERK_SECRET_KEY. Avec Next.js 16, le fichier middleware s'appelle proxy.ts.
Supabase Auth
Un client serveur créé à chaque requête à partir du magasin de cookies, avec la clé publishable. getClaims() vérifie le jeton avant que vous vous y fiiez.
Better Auth
Montez le gestionnaire sur une route catch-all, puis lisez la session côté serveur avec les en-têtes de la requête.
Auth.js (next-auth v5 bêta)
auth.ts exporte handlers, auth, signIn et signOut. Définissez AUTH_SECRET (npx auth secret en crée un).
Votre propre cookie de session signé
Une version courte du modèle du guide Next.js : jose signe le contenu et le cookie est HttpOnly, Secure et SameSite=Lax.
Où vérifier la session
Vérifications d'authentification par emplacement (d'après le guide d'authentification Next.js)
Emplacement
Type de vérification
Pourquoi
Optimiste, cookie uniquement
Redirections rapides ; s'exécute avant le rendu, y compris lors des préchargements
Couche d'accès aux données
Sûre
Un seul verifySession() par lequel passe chaque lecture de données
Server Actions
Sûre
Traitées comme des points d'accès publics ; vérifiez le rôle avant toute modification
Route Handlers
Sûre
401 si l'utilisateur est déconnecté, 403 si le rôle ne convient pas
Layouts
À éviter
Pas réaffichés lors de la navigation, les vérifications peuvent donc être sautées
Clerk
Le plus rapide pour obtenir une page de connexion fonctionnelle ; les utilisateurs sont chez Clerk.
Supabase Auth
Les utilisateurs sont dans votre Postgres Supabase ; les offres payantes facturent les utilisateurs au-delà du quota inclus.
Better Auth
Bibliothèque intégrée à votre application, écrit dans votre base de données, avec des plugins pour les extras.
Option de longue date, qui fait désormais partie de Better Auth ; la v5 est encore publiée en bêta.
Solution maison
Contrôle total ; vous écrivez chaque parcours et en assurez la sécurité.
Les données des utilisateurs restent dans une base que je contrôle
Écrans de connexion et de profil prêts à l'emploi
Aucun frais par utilisateur de la part du fournisseur d'authentification
Connexion liée à la sécurité au niveau des lignes de Postgres
Sélecteur d'option d'authentification
Cochez les exigences qui comptent et la liste ne garde que les options qui les remplissent toutes.
Exigences
Aucune option ne remplit à elle seule toutes les exigences cochées. Décochez-en une pour comparer.