L'enjeu : la conversion, et un écart dans Medusa
Medusa s'est imposé comme le moteur e-commerce open source de référence pour les boutiques sur mesure, et son intérêt business est simple à résumer : le code vous appartient, aucune commission ne s'ajoute sur vos ventes, et la plateforme se plie à votre métier plutôt que l'inverse. On a détaillé ce comparatif dans notre article Shopify vs Medusa.
Sur l'authentification en revanche, Medusa v2 s'en tient volontairement au minimum : la connexion par email et mot de passe. Pas de connexion Google ou Apple, pas de liens magiques envoyés par email qui connectent en un clic, pas de passkeys par empreinte ou reconnaissance faciale. Ce n'est pas un défaut de conception, Medusa se concentre sur le commerce et laisse l'authentification avancée à des outils spécialisés. Mais l'écart est là, et il se paie deux fois : en comptes non créés côté boutique, et en développement sur mesure côté projet, à refaire à chaque fois, dans l'un des domaines où le code artisanal est le plus risqué.
Ce qu'on a construit
Pour combler cet écart, on a développé un plugin open source qui relie Medusa v2 à Better Auth, la référence de l'authentification dans l'écosystème TypeScript. Il est né d'un vrai projet e-commerce qu'on prépare pour la production, il est publié sous licence MIT sur npm, référencé dans l'écosystème de plugins Medusa, et d'autres développeurs l'ont déjà adopté dans leurs propres boutiques.
Concrètement, le plugin apporte à n'importe quelle boutique Medusa v2 :
- La connexion sociale via huit fournisseurs, Google, Apple, Facebook, Microsoft, Discord, TikTok, X et GitHub, activables chacun avec deux variables d'environnement, boutons et icônes inclus.
- Les liens magiques, les passkeys et la double authentification, via l'écosystème de plugins Better Auth.
- Un widget de connexion pour le tableau de bord d'administration, avec les boutons sociaux au-dessus du formulaire classique.
- Une commande de migration pour les déploiements en production, idempotente, à lancer à chaque mise en ligne sans risque.
- La normalisation des emails clients, pour rendre les comptes en double impossibles.
Et surtout, il apporte tout ça sans rien casser. C'est le choix d'architecture qui a tout structuré.
Un pont, pas un remplacement
Le plugin ne remplace pas l'authentification de Medusa, il la complète. Better Auth tourne à l'intérieur du serveur Medusa, avec ses tables rangées dans la même base Postgres sous le préfixe ba_. Il gère le flux de connexion moderne, puis un provider d'authentification Medusa dédié valide la session et laisse Medusa émettre son propre jeton natif, celui d'un client ou celui d'un administrateur. Le storefront, l'admin et les routes protégées continuent de fonctionner avec l'authentification standard de Medusa, sans une ligne modifiée. Le modèle natif reste la source de vérité.
Autre conséquence de ce choix : aucun coût permanent en performance. Better Auth n'intervient qu'au moment du login. Ensuite, les clients naviguent avec leur jeton Medusa natif, et le plugin sort du chemin.
Un back office verrouillé
Une connexion sociale ne peut jamais créer un compte administrateur. Une identité Google ne peut être rattachée qu'à un administrateur déjà existant, invité normalement dans Medusa, et uniquement si le fournisseur a vérifié l'adresse email. Sans cette règle stricte, un login social mal configuré deviendrait une porte d'entrée sur les coulisses de la boutique. On l'a rendue non négociable.
Des comptes clients en double impossibles
Sans garde-fou, un client qui écrit son email avec une majuscule un jour et en minuscules le lendemain se retrouve avec deux comptes distincts : historique de commandes éclaté, confusion au support, statistiques faussées. Le plugin normalise les emails à la source, tout en respectant la façon dont Medusa sépare les commandes passées en invité des comptes clients. Aucune fusion automatique sur la seule base d'un email : le rattachement passe par le flux de transfert de commande de Medusa, qui exige une preuve de possession de la boîte mail.
Pensé pour la production, documenté avec ses limites
La documentation du plugin couvre ce qui casse habituellement une mise en ligne : la limitation de débit à passer sur un stockage partagé derrière un load balancer, les cookies à configurer entre le domaine de la boutique et celui de l'API, le nettoyage périodique des sessions expirées, la surveillance des connexions Postgres. Elle assume aussi les limites connues, versions vérifiées, cas particuliers selon le gestionnaire de paquets, points encore en chantier. Un composant d'authentification qui cache ses limites est un composant auquel on ne peut pas faire confiance.
Ce que ça change pour un projet e-commerce
L'équation se lit à deux niveaux. Medusa d'abord : une boutique dont vous possédez le code, sans commission prélevée sur vos ventes, et qui reproduit vos règles métier au lieu de vous imposer les siennes. Ce plugin ensuite, qui lève ce qui était l'une des vraies réserves face aux plateformes clés en main : la connexion moderne, celle qui réduit la friction à l'inscription et protège la conversion, n'est plus un chantier à ouvrir sur votre budget. C'est une brique existante à poser, dont les pièges de mise en production sont déjà identifiés et traités. L'écart de confort avec une solution propriétaire se referme, les avantages structurels de l'open source restent.
Chez Nualt, c'est notre façon de travailler : construire nos boutiques sur Medusa, et quand une pièce manque, la fabriquer proprement et la rendre à l'écosystème plutôt que de la garder dans un tiroir. Que d'autres développeurs aient lu le code et choisi de l'installer est la validation la plus honnête qui soit.
Questions fréquentes sur l'authentification Medusa et le plugin
Les questions qui reviennent le plus souvent sur l'authentification dans Medusa v2 et sur ce que couvre le plugin, en réponses courtes. Pour le détail technique complet, la documentation du plugin sur GitHub reste la référence.
Medusa v2 gère-t-il nativement la connexion Google ou les magic links ?
Non. Le module natif couvre la connexion par email et mot de passe. Le social login, les liens magiques, les passkeys et la double authentification demandent un outil complémentaire comme Better Auth, relié à Medusa par un connecteur dédié, ce que fait précisément ce plugin.
Que contient exactement notre plugin ?
La connexion sociale via huit fournisseurs configurables par variables d'environnement, les liens magiques, les passkeys et la 2FA via Better Auth, un widget de connexion pour l'admin, une commande de migration pour la production et la normalisation des emails clients. Le tout sans modifier le modèle de session natif de Medusa.
Faut-il remplacer l'authentification de Medusa pour l'utiliser ?
Non, et c'est le cœur de son architecture. Better Auth gère la connexion, puis Medusa émet son propre jeton natif. Le storefront, l'admin et les routes protégées continuent de fonctionner sans modification.
Une connexion sociale peut-elle créer un compte administrateur ?
Jamais. Une identité sociale ne peut être rattachée qu'à un administrateur déjà invité dans Medusa, et seulement si le fournisseur a vérifié l'email. C'est une règle de sécurité volontairement non négociable.
Pourquoi choisir Medusa pour un e-commerce si l'authentification moderne n'est pas native ?
Parce que les avantages structurels de Medusa restent entiers : propriété du code, aucune commission sur les ventes, liberté totale sur les règles métier. L'authentification moderne était l'un des écarts de confort face aux plateformes clés en main, et ce plugin le referme. Le choix de plateforme se fait sur les fondations, pas sur une fonctionnalité qui s'ajoute.
