L'authentification est la fondation de chaque SaaS. Ratez-la et vous faites face à des vulnérabilités de sécurité, des problèmes d'expérience utilisateur et des semaines de debugging. Faites-la bien dès le premier jour et elle disparaît — elle fonctionne juste.
Ce guide couvre à quoi ressemble une authentification de niveau production dans une application Next.js 14 App Router.
Ce que l'auth en production requiert vraiment
Un formulaire de login n'est pas un système d'authentification. Un système d'auth complet inclut : l'inscription avec vérification email, le login avec gestion sécurisée des sessions, la réinitialisation de mot de passe avec tokens à durée limitée, le contrôle d'accès basé sur les rôles, la protection des routes admin, le blocage des adresses email jetables, et une gestion correcte des erreurs pour chaque cas d'échec.
La plupart des tutoriels couvrent le formulaire de login. Le reste, c'est ce qui fait la différence entre un projet jouet et un vrai produit.
Vérification email : pourquoi c'est non-négociable
Sans vérification email, n'importe qui peut s'inscrire avec une fausse adresse email. Cela crée des problèmes : vous ne pouvez pas contacter vos utilisateurs, votre délivrabilité email en souffre, et les utilisateurs malveillants peuvent s'inscrire librement sans responsabilité.
L'implémentation correcte : à l'inscription, créez l'utilisateur avec emailVerified défini à null. Envoyez un email de vérification avec un token à durée limitée. Quand l'utilisateur clique sur le lien, définissez emailVerified au timestamp actuel. Bloquez les utilisateurs non vérifiés d'accéder aux fonctionnalités protégées.
Dans NextAuth.js avec un auth.ts personnalisé, vous vérifiez emailVerified dans le callback authorize et lancez une erreur personnalisée (EMAIL_NOT_VERIFIED) que le client peut gérer pour afficher le message approprié.
Contrôle d'accès basé sur les rôles
La plupart des produits SaaS ont besoin d'au moins deux rôles : les utilisateurs réguliers et les administrateurs. Le rôle est stocké sur le modèle User dans votre base de données et inclus dans la session NextAuth.
Chaque Route Handler admin doit appeler getServerSession et vérifier que session.user.role === 'ADMIN'. Retournez une réponse 403 pour les requêtes non autorisées. Ne vous fiez jamais aux vérifications côté client seules — elles peuvent être contournées.
Gestion des sessions : email vs ID
Une décision architecturale subtile mais importante : utilisez session.user.email comme identifiant principal pour les recherches en base de données, pas session.user.id.
Pourquoi ? NextAuth n'inclut pas toujours l'ID utilisateur dans la session par défaut, et le comportement peut être incohérent selon l'adapter et la stratégie de session. L'email est toujours présent et est un identifiant unique stable.
Chaque recherche d'utilisateur dans vos Route Handlers doit utiliser findUnique({ where: { email: session.user.email } }).
Blocage des emails jetables
Les services d'email jetables (mailinator, tempmail et des centaines d'autres) sont utilisés pour créer des faux comptes, abuser des essais gratuits et éviter les bannissements. Bloquez-les à l'inscription en maintenant une liste de domaines jetables connus et en rejetant toute adresse email dont le domaine apparaît dans la liste.
Une liste de 200+ domaines jetables offre une bonne couverture sans faux positifs.
Le flux de réinitialisation de mot de passe
La réinitialisation de mot de passe nécessite : un formulaire pour demander la réinitialisation (entrez votre email), un Route Handler qui crée un token à durée limitée et envoie l'email de réinitialisation, une page pour entrer le nouveau mot de passe (avec le token dans l'URL), et un Route Handler qui vérifie le token, vérifie qu'il n'est pas expiré, met à jour le mot de passe et invalide le token.
Le token doit être à usage unique et doit expirer (15 à 60 minutes est standard). Stockez une version hachée du token dans la base de données, pas le token brut.
L'authentification AliyaSaas
AliyaSaas implémente tout cela correctement : vérification email avec blocage, contrôle d'accès basé sur les rôles, recherches par email en session, 200+ domaines d'email jetables bloqués, et un flux complet de réinitialisation de mot de passe. La configuration auth est dans src/lib/auth.ts et est entièrement documentée.
Vous pouvez lire le code, comprendre chaque décision et le personnaliser selon vos besoins. Ou vous pouvez le déployer tel quel et avoir une authentification de niveau production fonctionnant immédiatement.