Better Auth (Auth open source TypeScript)
#Définition Better Auth (Auth open source TypeScript)
Better Auth est une bibliothèque d'authentification TypeScript open source créée en 2024, alternative moderne à NextAuth (Auth.js), Lucia Auth et Clerk. Fonctionnalités natives : (1) email/password avec hachage Argon2/bcrypt configurable, (2) OAuth providers (Google, GitHub, Microsoft, Apple, Discord, etc.), (3) magic links par e-mail, (4) passkeys/WebAuthn conformes FIDO2, (5) 2FA TOTP (compatible Google Authenticator, 1Password), (6) multi-tenant avec organizations et invitations, (7) RBAC (Role-Based Access Control) granulaire. Pour approfondir, consultez la page service Applications Web Next.js 16.
D'un point de vue métier, Compatible Next.js 16 (App Router + Server Actions), SvelteKit, Astro, React Router v7, Tanstack Start. Stockage agnostique via adapters : Postgres, MySQL, SQLite, MongoDB, Drizzle, Prisma. Auto-hébergeable (vs Clerk SaaS verrouillé chez un fournisseur US) — contrôle total des données utilisateurs, conformité RGPD native. Stack par défaut Nehos pour ses projets clients : souveraineté maximale plus flexibilité d'extension.
Le concept de Better Auth (Auth open source TypeScript) prend tout son sens dans un contexte B2B où chaque décision technique impacte directement le ROI.
#Better Auth (Auth open source TypeScript) expliqué simplement
Better Auth = bibliothèque moderne pour gérer l'authentification des utilisateurs dans une application Next.js. Tu l'installes en cinq minutes et tu obtiens : login email/mot de passe, OAuth Google ou Microsoft, magic links par e-mail, passkeys (le successeur du mot de passe) et 2FA.
Le tout open source et auto-hébergeable — pas comme Clerk qui stocke tes utilisateurs sur ses propres serveurs aux États-Unis. Chez Nehos, c'est notre stack d'authentification par défaut pour les clients : on garde la souveraineté et le contrôle, sans dépendre d'un SaaS étranger.
Situation classique dans les projets que Nehos accompagne. C'est la réalité du terrain — loin des définitions académiques.
#Cas d'usage concrets
Scale-up SaaS B2B — stack souveraine France — Exemple de situation : un SaaS B2B qui vend à des entreprises clientes combine Better Auth, Postgres hébergé en France et Stripe Connect. Les organizations multi-tenant sont natives, le RBAC distingue admin, manager et lecteur, et les passkeys sont activés pour les comptes admin. Partir de Better Auth évite une migration ultérieure depuis un SaaS d'authentification facturé à l'utilisateur actif.
Collectivité — site agent + FranceConnect+ + RGAA — Exemple de situation : le portail interne d'une collectivité couple Better Auth à FranceConnect+ via un OIDC custom provider. L'authentification forte vise les exigences de l'ANSSI, l'accessibilité vise le RGAA et le stockage Postgres peut être confié à un hébergeur qualifié SecNumCloud. Better Auth est retenu pour son extensibilité : l'adapter OIDC custom se branche proprement, ce qui est plus difficile sur Clerk.
MVP startup studio Nehos — mise en place rapide — Exemple de situation : pour un MVP, Better Auth s'installe rapidement : email/password, OAuth Google, magic links et passkeys. Aucune dépendance à un SaaS d'authentification dès le premier jour, ce qui évite des migrations douloureuses lors d'une levée de fonds.
#Better Auth (Auth open source TypeScript) chez Nehos Groupe
On intègre cette approche dans chaque projet client. Notre service Applications Web Next.js 16 couvre ce périmètre de A à Z.
La méthode Nehos est documentée sur méthode Stack Tech Nehos par défaut. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. On livre, on mesure, on itère. Pas de slides sans livrable.
#Termes associés
Pour aller plus loin, explorez les termes connexes.
- NextAuth (Auth.js — concurrent open source)
- Clerk (SaaS auth — vendor lock-in US)
- FranceConnect+ (identité numérique régalienne)
- Passkeys (authentification sans mot de passe FIDO2)
- OAuth 2.0 (protocole d'autorisation standard)
- Magic links (authentification par e-mail à usage unique)
- WebAuthn (standard W3C authentification forte)
Explorez chaque définition pour construire une vision complète du sujet.
Applications Concrètes
« Exemple de situation : un SaaS B2B qui vend à des entreprises clientes combine Better Auth, Postgres hébergé en France et Stripe Connect. Les organizations multi-tenant sont natives, le RBAC distingue admin, manager et lecteur, et les passkeys sont activés pour les comptes admin. Partir de Better Auth évite une migration ultérieure depuis un SaaS d'authentification facturé à l'utilisateur actif. »
« Exemple de situation : le portail interne d'une collectivité couple Better Auth à FranceConnect+ via un OIDC custom provider. L'authentification forte vise les exigences de l'ANSSI, l'accessibilité vise le RGAA et le stockage Postgres peut être confié à un hébergeur qualifié SecNumCloud. Better Auth est retenu pour son extensibilité : l'adapter OIDC custom se branche proprement, ce qui est plus difficile sur Clerk. »
« Exemple de situation : pour un MVP, Better Auth s'installe rapidement : email/password, OAuth Google, magic links et passkeys. Aucune dépendance à un SaaS d'authentification dès le premier jour, ce qui évite des migrations douloureuses lors d'une levée de fonds. »
Questions & réponses
Questions fréquentes sur Better Auth
Trois raisons concrètes nous font privilégier Better Auth chez Nehos. D'abord la DX : Better Auth expose une API typée TypeScript de bout en bout, là où NextAuth garde un héritage JavaScript et des callbacks parfois pénibles à typer. Ensuite la richesse native : organizations, RBAC, passkeys, 2FA TOTP sont inclus sans plug-ins tiers, alors que NextAuth oblige à coller plusieurs librairies. Enfin la philosophie : Better Auth est agnostique de framework (Next.js, SvelteKit, Astro, Tanstack Start), ce qui aligne notre stack quand un client change de framework. Réserve honnête : NextAuth a un écosystème plus ancien, donc plus de tutoriels et de réponses Stack Overflow.
On perd trois confort : le dashboard utilisateurs prêt à l'emploi, le support payant et les fonctionnalités enterprise (SCIM, SAML clés en main). On gagne en revanche la souveraineté totale des données (RGPD natif, pas de DPA avec un éditeur US), le contrôle des coûts (Clerk facture à l'utilisateur actif ; Better Auth ne coûte rien hors infrastructure), et l'absence de vendor lock-in. Migrer hors de Clerk après coup est un vrai chantier — autant ne pas s'y enfermer dès le départ si la souveraineté est un critère business.
Oui, via le mécanisme de generic OIDC provider. FranceConnect+ expose un endpoint OpenID Connect standard, et Better Auth permet d'enregistrer un custom OIDC provider en une trentaine de lignes de configuration (clientId, clientSecret, issuer, scopes eIDAS substantiel). Associé à un audit de sécurité et à un stockage Postgres chez un hébergeur qualifié SecNumCloud, c'est une base solide pour une collectivité. À noter : FranceConnect+ exige une convention DINUM et un dossier homologation RGS — Better Auth n'enlève pas cette obligation administrative.
Non, et c'est même contre-productif en 2026. Les passkeys sont une excellente option pour les comptes sensibles (admin, finance, RH) et pour les utilisateurs technophiles, mais le grand public n'est pas encore prêt — beaucoup confondent passkey, mot de passe Apple ID et iCloud Keychain. Notre approche par défaut chez Nehos : passkeys proposés en option à l'inscription, fortement encouragés pour les rôles admin, obligatoires sur les accès production. Better Auth gère nativement le fallback email/password ou magic link, ce qui évite de bloquer les utilisateurs qui ratent leur enrôlement passkey.
Trois étapes pragmatiques. Étape 1 : installer Better Auth en parallèle, sans casser NextAuth (les deux peuvent coexister sur des routes différentes pendant 2 à 4 semaines). Étape 2 : importer les utilisateurs depuis la table NextAuth (User, Account, Session) vers le schéma Better Auth — l'éditeur fournit un script de migration officiel pour Postgres et MySQL. Étape 3 : bascule progressive route par route, jusqu'à supprimer NextAuth du code base. Le délai dépend du nombre d'utilisateurs et de la complexité des comptes ; on l'évalue lors d'un cadrage. Point d'attention : si vous utilisez les JWT NextAuth en cookie, prévoyez une période où les deux cookies coexistent pour ne pas déloguer brutalement les utilisateurs.