For AI agents: fetch the complete documentation index at /llms.txt, the full documentation corpus at /llms-full.txt, the agent skill at /skill.md, or this page as Markdown at /fr/docs/web/authentication.md (or send Accept: text/markdown).
Authentification
Méthodes de connexion, sessions et sécurité du compte.
Créer et vérifier un compte réel
L'authentification signifie prouver qui utilise l'application. Démarrez Postgres et exécutez d'abord les migrations à l'aide du guide de base de données, puis laissez le serveur Web en cours d'exécution. Ouvrez http://localhost:3000/auth,, choisissez inscription par e-mail/mot de passe, entrez votre nom, votre e-mail et votre mot de passe, puis soumettez. Conservez EMAIL_PROVIDER=local pour ce premier test.
Lorsqu'un flux demande un code de courrier électronique, ouvrez http://localhost:3000/mail-preview dans un autre onglet du navigateur, recherchez le message le plus récent pour cette adresse et recopiez son code dans le formulaire de connexion. Demandez un nouveau code s’il expire. Ces messages restent dans la boîte d'envoi locale ; vérifier à plusieurs reprises une boîte de réception externe ne les trouvera pas. Déconnectez-vous, puis reconnectez-vous pour confirmer que le compte sauvegardé par la base de données fonctionne.
Si l'inscription signale une connexion à la base de données ou une erreur de table manquante, terminez la configuration de la base de données au lieu d'activer la connexion sociale. Les boutons Google, GitHub, Apple, X et Microsoft nécessitent leur propre application fournisseur et leurs propres paramètres de rappel ; activez-en un uniquement une fois son guide du fournisseur terminé. Better Auth est le moteur par défaut livré et ne nécessite pas de compte d'authentification payant pour la connexion par courrier électronique local.
Choisir les méthodes de connexion activées
La base comprend la connexion par e-mail et mot de passe, les codes OTP et l’authentification sociale configurable. Better Auth gère l’identité et les sessions, tandis que l’application compose la configuration des fournisseurs et l’envoi transactionnel des codes OTP.
Activez uniquement les fournisseurs sociaux que vous avez configurés. Les secrets client des fournisseurs et le secret d’authentification restent côté serveur.
Relier l’identité à un espace de travail
Les gestionnaires authentifiés résolvent l’état de la session avant d’accéder aux données de l’espace de travail. La création d’un espace de travail doit rester idempotente afin que la répétition d’un hook de cycle de vie ne crée pas de doublons dans les enregistrements de propriété.
Vérifier le comportement des sessions
Testez la connexion, les codes OTP invalides ou expirés, leur utilisation unique, la déconnexion et le refus des accès anonymes. Les tests avec adaptateur mémoire couvrent la sémantique des gestionnaires ; la persistance en base de données en production et les vrais rappels des fournisseurs nécessitent une validation distincte.
Configuration et paramètres
Better Auth est le moteur par défaut (AUTH_PROVIDER=better-auth) ; un moteur Auth.js est disponible pour les équipes qui s'y standardisent. Les méthodes activées se déclarent par fournisseur : e-mail/mot de passe, codes à usage unique livrés par e-mail transactionnel, et connexion sociale pour Google, Apple, GitHub, Microsoft et Twitter.
Chaque fournisseur social s'active avec son drapeau AUTH_<PROVIDER>_ENABLED plus l'ID client et le secret correspondants. Le secret d'authentification, les secrets fournisseurs et les clés de signature de session sont une configuration réservée au serveur.
AUTH_PROVIDER=better-auth
AUTH_SECRET=generate-a-long-random-value
AUTH_GOOGLE_ENABLED=true
GOOGLE_CLIENT_ID=…
GOOGLE_CLIENT_SECRET=…Processus d’implémentation
La surface /auth rend les méthodes configurées ; le serveur compose le moteur dans auth-runtime et résout la session à chaque frontière protégée. Une première connexion réussie provisionne le workspace personnel du membre de façon idempotente — des hooks de cycle de vie rejoués ne doivent jamais créer un second enregistrement de propriété.
La sécurité du compte vit sous /settings/security : changement de mot de passe, sessions actives et passkeys lorsque le build les active. Gardez la restauration de session, la révocation à la déconnexion et le refus inter-workspaces comme comportement appliqué côté serveur, pas comme état d'interface.
Vérification et dépannage
Exercez la connexion, les codes OTP invalides et expirés, la consommation à usage unique, les cérémonies passkey sur des origines HTTPS, les retours de callback sociaux, la déconnexion et le refus anonyme. Enregistrez chaque URI de redirection fournisseur avant de tester les callbacks, et vérifiez qu'une session révoquée ne peut plus effectuer de travail protégé.