Laissez un système posséder l'identité
Le formulaire de connexion collecte une requête. Le système d'authentification décide si cette requête établit une identité et émet la session à laquelle le reste de l'application fait confiance. Garder cette responsabilité en un seul endroit empêche chaque route d'inventer sa propre interprétation d'un utilisateur connecté.
supastack compose Better Auth pour l'identité et la gestion de session. Le code applicatif résout la session aux frontières protégées et la relie à un espace de travail. L'interface peut montrer des états d'accès utiles, mais l'état client ne doit pas devenir une preuve qu'une opération est autorisée.
La règle doit valoir sur chaque surface livrée par le produit. Les clients web, mobile et bureau doivent consommer la même décision d'identité plutôt que de l'implémenter trois fois — trois interprétations de « connecté », voilà d'où viennent les bugs de compte.
Choisissez les méthodes de connexion délibérément
Chaque méthode échange de la friction contre de la surface d'attaque et une dépendance externe. Les mots de passe exigent des flux de réinitialisation et une limitation de débit. Les magic links et codes à usage unique dépendent de la délivrabilité de l'e-mail. OAuth délègue l'identité à des fournisseurs comme Google, GitHub ou Apple — et hérite de leurs pannes, écrans de consentement et règles de callback.
supastack les compose via Better Auth — OTP par e-mail, mot de passe, magic link, OAuth, avec la double authentification et les passkeys disponibles — derrière une seule décision d'identité. Livrez le plus petit ensemble dont votre audience a réellement besoin ; chaque méthode supplémentaire est un chemin de callback de plus, un mode d'échec de plus et un flux de plus à vérifier avant le lancement. Le guide d'authentification couvre le câblage.
Quand une personne peut se connecter de plus d'une façon, décidez comment les méthodes se rejoignent. Un compte Google et un magic link e-mail qui résolvent à la même adresse doivent aboutir sur une seule identité, pas deux. Les règles de liaison de comptes font partie de la décision d'identité, et les rater crée des utilisateurs en double qui refont surface des mois plus tard sous forme de données mystérieusement manquantes.
Les sessions sont l'identifiant qui compte
Après la connexion, c'est la session — pas le mot de passe — que chaque requête transporte. Ses règles d'expiration, de stockage et d'invalidation définissent la vraie posture de sécurité. Une session qui survit à la déconnexion, ou qu'un membre retiré de l'espace peut continuer d'utiliser, est un échec d'authentification qu'aucun bel écran de connexion ne peut réparer.
Décidez le cycle de vie dès le départ : combien de temps vivent les sessions, si les utilisateurs peuvent voir et révoquer leurs sessions actives, et ce qu'un changement de mot de passe, un changement d'e-mail ou un retrait d'espace leur fait. La gestion de session existe comme module dans le kit précisément parce que ces décisions sont faciles à reporter et coûteuses à rajouter après coup.
Reliez la session à l'enregistrement demandé
Être connecté ne donne pas accès à tous les enregistrements. Résolvez l'espace de travail de l'utilisateur côté serveur et incluez ce périmètre dans les lectures et mutations. Un identifiant de tâche ou un lien de reprise est une référence à un travail, pas une permission de le récupérer — l'article sur les frontières d'espace de travail couvre ce côté de la frontière en détail.
Résolvez le périmètre dans un ordre fixe : authentifiez la session, chargez l'appartenance, puis lisez ou écrivez avec ce contexte d'espace — jamais dans l'autre sens. Un middleware peut rediriger un visiteur anonyme, mais il ne peut pas autoriser l'opération ; le contrôle appartient à l'action serveur ou au gestionnaire de route où l'enregistrement est touché.
Les comptes ont un cycle de vie, pas seulement un début
Le provisionnement est le premier test de cette frontière. Quand un utilisateur s'inscrit, l'espace de travail et les enregistrements d'appartenance qui suivent doivent pouvoir être créés plus d'une fois sans danger — les hooks de cycle de vie peuvent être rejoués par les fournisseurs, les retries ou les outils de support. Un événement en double doit être un no-op, pas une organisation en double.
La fin du cycle de vie mérite le même soin. Changements d'e-mail, réinitialisations de mot de passe, retraits de membres, suppressions de compte et exports de données sont chacun de petits flux avec leurs propres cas d'abus — un lien de réinitialisation qui marche deux fois, un export qui fuit les enregistrements d'un coéquipier. supastack livre l'export GDPR et la gestion de session pour cette raison ; quel que soit votre socle, budgétez les flux ennuyeux.
Testez le cycle de vie, y compris sa fin
Un test de connexion réussi est utile mais incomplet. Exercez les identifiants invalides, les codes de vérification expirés ou réutilisés, les requêtes anonymes et l'accès entre espaces. Vérifiez que la déconnexion invalide la session et qu'un client revenant ne peut pas continuer à utiliser un écran précédemment autorisé pour du travail protégé.
Distinguez les tests de handler de l'acceptation en déploiement. Un adaptateur mémoire peut établir la sémantique d'un vrai handler d'authentification sans prouver la persistance Postgres ni un callback fournisseur. Vérifiez l'origine configurée, le chemin de callback, la restauration de session et la déconnexion avec les dépendances déployées avant d'affirmer que le parcours de connexion complet fonctionne.
- Les identifiants invalides et les codes de vérification expirés ou réutilisés sont rejetés.
- Les requêtes anonymes et inter-espaces ne reçoivent aucune donnée possédée.
- La déconnexion invalide la session — un client périmé ne peut pas continuer à agir.
- Les enregistrements provisionnés restent idempotents quand les hooks de cycle de vie se rejouent.
- Les callbacks des vrais fournisseurs fonctionnent sur l'origine configurée — vérifié, pas supposé.
Questions fréquentes sur l'authentification
Les questions ci-dessous remontent une fois le formulaire de connexion terminé, quand le système doit continuer à fonctionner.
- Un middleware suffit-il à protéger les routes ? — Un middleware est une redirection commode, pas une couche d'autorisation. Chaque action serveur et chaque route résout elle-même la session et l'espace ; les gardes au niveau page masquent des écrans sans autoriser les opérations.
- Construire l'auth moi-même ou utiliser une bibliothèque ? — La sémantique de session est rarement l'endroit où un SaaS se différencie. Une bibliothèque maintenue comme Better Auth derrière des frontières de module claires vous donne des primitives testées tout en gardant dans votre code les décisions qui comptent — périmètre, cycle de vie.
- Quel lien entre sessions et espaces de travail ? — La session identifie la personne ; l'espace de travail identifie les enregistrements qu'elle peut toucher. Résolvez l'appartenance côté serveur à chaque requête et ne faites jamais confiance à un ID d'espace envoyé par le client.
- Qu'attendent les clients B2B de l'authentification ? — Des espaces d'équipe avec rôles, la connexion OAuth, la visibilité et la révocation des sessions, et une piste d'audit. La double authentification et les passkeys sont de plus en plus attendues pour les rôles admin.
- Qu'est-ce qui casse l'authentification en production ? — Généralement les bords : une URL de callback qui n'existe qu'en local, un hook qui provisionne deux fois, une session qui survit à une appartenance. Testez les fins de flux, pas seulement les débuts.