NextAuth est le nom historique du projet aujourd’hui documenté sous Auth.js. Clerk est un service d’identité managé avec SDK et composants Next.js. Le choix oppose surtout contrôle et responsabilité : Auth.js s’intègre à votre stockage et votre logique, Clerk prend en charge davantage de parcours et d’infrastructure.
Auth.js : composer sa solution
Auth.js convient lorsque l’équipe veut maîtriser fournisseurs, sessions, callbacks, base et interface. Il s’intègre naturellement à une application existante, mais vous restez responsable des écrans, emails, récupération de compte, sécurité opérationnelle et parfois de la gestion des organisations. Épinglez la documentation correspondant à votre version.
Clerk : produit d’identité intégré
Clerk fournit composants, hooks, helpers serveur, gestion des utilisateurs et fonctions d’organisation. Il accélère fortement l’onboarding. Dans l’App Router, l’intégration utilise son provider, ses helpers serveur et une couche proxy ou middleware selon la version de Next.js. Vérifiez prix, régions, export, personnalisation et dépendance au service.
Authentification n’est pas autorisation
Dans les deux cas, vérifiez côté serveur si l’utilisateur peut accéder à la ressource et à quel tenant elle appartient. Protéger une route ou cacher un bouton ne suffit pas. Testez expiration, révocation, changement de rôle, CSRF selon le flux, redirections et webhooks rejoués.
Arbre de décision
Choisissez Clerk si le délai, les composants et les organisations managées priment. Choisissez Auth.js si vous voulez contrôler l’architecture et disposez des compétences nécessaires. Une solution d’identité métier ou entreprise peut s’imposer pour SSO, conformité ou annuaire existant.
FAQ
NextAuth et Auth.js sont-ils deux produits ?
Auth.js est l’évolution du projet historiquement appelé NextAuth.js.
Clerk protège-t-il toutes les routes par défaut ?
Ne le supposez pas : configurez explicitement les ressources protégées selon la documentation actuelle.
Où stocker les rôles ?
Dans une source serveur fiable et vérifiée à chaque opération sensible.
Exemple Auth.js avec App Router
~~~typescript // auth.ts import NextAuth from 'next-auth' import GitHub from 'next-auth/providers/github'
export const { auth, handlers, signIn, signOut } = NextAuth({ providers: [GitHub], session: { strategy: 'jwt' }, }) ~~~
~~~typescript // app/api/auth/[...nextauth]/route.ts import { handlers } from '@/auth' export const { GET, POST } = handlers ~~~
~~~typescript // app/dashboard/page.tsx import { auth } from '@/auth' import { redirect } from 'next/navigation'
export default async function Page() { const session = await auth() if (!session?.user) redirect('/api/auth/signin') return <h1>Tableau de bord</h1> } ~~~
L’authentification prouve une identité ; elle ne remplace pas l’autorisation. Contrôlez rôle et propriété de la ressource dans chaque mutation serveur. Validez les URL de redirection et conservez les secrets uniquement côté serveur.