> ## Documentation Index > Fetch the complete documentation index at: https://supastack.dev/llms.txt > Use this file to discover all available pages before exploring further. > For the full documentation corpus in one file, fetch: https://supastack.dev/llms-full.txt # 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. [Démarrez Postgres avant de créer un compte](https://supastack.dev/fr/docs/web/database.md) [Utiliser et dépanner les codes de connexion par courrier électronique](https://supastack.dev/fr/docs/web/setup-ai.md) [Configurer la connexion Google](https://supastack.dev/fr/docs/web/setup-oauth.md) [Ajouter la connexion Google](https://supastack.dev/fr/docs/web/google-sign-in.md) [Ajouter la connexion GitHub](https://supastack.dev/fr/docs/web/github-sign-in.md) [Ajouter la connexion Apple](https://supastack.dev/fr/docs/web/apple-sign-in.md) ## 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__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é. ## Suivant [Organisations et invitations](https://supastack.dev/fr/docs/web/organizations.md)