L'authentification est souvent le moment où un projet TypeScript ralentit. Il faut choisir le stockage des sessions, gérer les comptes, prévoir les organisations et ne pas oublier la récupération de compte. J'ai testé Better Auth parce que je voulais une base lisible, que je puisse adapter à mes applications sans cacher tous les choix derrière un service hébergé.
Ce que Better Auth simplifie
Better Auth reste indépendant de l'interface : React, Vue, Next.js, Astro ou Svelte peuvent consommer la même couche serveur. Cette séparation m'intéresse surtout quand le front change plus vite que l'API.
Une mise en place progressive
Si tu as déjà monté cette partie à la main, tu sais où se cachent les heures perdues. Better Auth fournit une connexion par email et mot de passe, la gestion des organisations et des plugins comme le 2FA. Tu peux commencer avec peu d'options, puis ajouter uniquement ce dont le projet a besoin.
Imagine, tu travailles sur une grosse application multi-utilisateur : tu peux gérer des organisations entières avec des accès différenciés. Pas mal, non ? Et tout ça, sans que tu te retrouves à configurer mille options obscures.
Les plugins et les types
Les plugins couvrent les besoins qui arrivent souvent après le premier prototype. Le typage TypeScript aide à repérer les mauvais paramètres avant l'exécution, mais il ne remplace pas une revue de la configuration ni des tests de parcours.
Et si tu n'as pas besoin de JWT ?
Better Auth ne pousse pas les JWT par défaut. C'est cohérent pour une application web qui garde ses sessions côté serveur. Si ton architecture impose des tokens, vérifie le plugin choisi et les conséquences sur la révocation, l'expiration et le partage entre services.
Un point important sur la version
Cet article a commencé comme un retour publié en 2024. Better Auth évolue rapidement : les plugins, les adaptateurs et les recommandations de déploiement peuvent changer. Vérifie la documentation et les changelogs du projet avant de reprendre un exemple dans une application en production. Je ne m'appuie plus ici sur un nombre d'étoiles ou sur le statut bêta d'une version donnée.
Un exemple d’utilisation
Bon, c’est bien beau tout ça, mais comment ça marche concrètement ? Voici un exemple basique pour que tu voies à quel point c’est simple de démarrer avec Better Auth.
import { betterAuth } from 'better-auth'; const auth = betterAuth({ database: { provider: 'postgresql', url: process.env.DATABASE_URL, // On récupère l'URL de la base de données depuis les variables d'environnement }, emailAndPassword: { enabled: true, // Authentification par email et mot de passe activée }, plugins: [ organization(), // Gestion des organisations twoFactor(), // Authentification à deux facteurs ], }); // Exemple d'utilisation pour gérer un utilisateur : auth.createUser({ email: 'user@example.com', password: 'securepassword123', }).then(user => { console.log('Utilisateur créé:', user); }).catch(err => { console.error('Erreur lors de la création de l\'utilisateur:', err); });
Tu vois, avec seulement quelques lignes, tu peux déjà connecter une base de données PostgreSQL, activer l’authentification par email et mot de passe, et ajouter des plugins comme le 2FA ou la gestion des organisations. C’est bien rapide à mettre en place !
Pour aller plus loin
Commence par la documentation officielle et teste les parcours qui comptent pour ton application : création de compte, révocation de session, récupération et 2FA. Une démo publique peut disparaître ou ne plus refléter la version installée ; je préfère donc te renvoyer vers la source et vers ton propre environnement de test.
Better Auth peut faire gagner du temps sur le démarrage, mais il ne supprime pas les décisions importantes : stockage des sessions, rotation des secrets, récupération de compte, 2FA et surveillance des événements. Je le considérerais comme une bonne base à évaluer sur un projet concret, pas comme une raison de déléguer toute la sécurité à une abstraction.
Article co-écrit avec l'IA · Images générées avec l'IA.