Consolider deux systèmes d'authentification sans déconnecter les utilisateurs existants

Le problème : deux connexions dans une même app et des utilisateurs coincés entre les deux

Deux systèmes de connexion séparés créent un état intermédiaire étrange pour les utilisateurs. Ils se connectent sur un écran, puis sont renvoyés vers une autre invite de connexion ailleurs. En test local ça peut sembler correct, tandis que les vrais utilisateurs rapportent des déconnexions aléatoires, un accès manquant ou des boucles de redirection infinies.

Les indices sont souvent peu glamours mais évidents une fois qu'on regarde : deux écrans de connexion différents, deux jeux de cookies aux noms similaires, et des vérifications d'authentification mixtes qui cherchent parfois un cookie de session et d'autres fois un JWT. Dans l'onglet réseau vous verrez peut-être un endpoint définissant un cookie comme session tandis qu'un autre définit quelque chose comme auth_token.

Ceci arrive souvent lors de prototypages rapides et de code généré par l'IA. Un outil ajoute un paquet d'auth prêt à l'emploi, puis plus tard un prompt ajoute une connexion personnalisée « juste pour l'instant », ou un template de framework est fusionné avec une API existante. Rien ne remplace complètement l'ancien chemin, donc les deux restent actifs.

Ce qui casse en premier est souvent la plomberie autour de la connexion, pas le formulaire lui‑même :

• Les réinitialisations de mot de passe mettent à jour une table users, mais l'app lit l'autre.
• La vérification d'email est appliquée dans un flux mais ignorée dans l'autre.
• Les rôles et permissions vérifient des claims différents ou des colonnes DB différentes.
• Les sessions "Se souvenir de moi" ne correspondent jamais au middleware qui protège les pages.

La partie risquée est que supprimer la mauvaise pièce peut verrouiller de vrais utilisateurs sans avertissement. Vous supprimez un cookie « en double » et pensez avoir nettoyé, mais ce cookie peut être la seule chose qui garde valides des sessions anciennes. Ou vous supprimez une table de sessions « inutilisée » et découvrez que des jobs en arrière-plan (ou un client mobile) en dépendaient pour rafraîchir des jetons.

Traitez la consolidation comme une migration d'utilisateurs, pas comme un rangement de code. L'objectif est une source de vérité claire, avec un chevauchement contrôlé pour que les comptes et sessions existants continuent de fonctionner.

Faire un inventaire clair de ce qui existe aujourd'hui

Avant de modifier quoi que ce soit, listez chaque élément mobile d'auth. La plupart des échecs de consolidation surviennent parce qu'une vérification invisible (middleware, garde API, fonction edge) attend encore l'ancien cookie ou l'ancien format de session.

Nommez les deux approches en termes simples, même si le code est en désordre. Par exemple : "NextAuth cookie session" vs "JWT personnalisé dans localStorage". Puis notez ce que chaque système contrôle : l'UI de connexion, l'accès API, les enregistrements en base, les pages admin, les jobs en arrière-plan et tout callback tiers.

Pour chaque système, répondez à ces questions :

• Qu'est‑ce qui prouve que l'utilisateur est connecté (nom du cookie, header, format du token) ?
• Où est‑ce appliqué (middleware, routes serveur, fonctions edge, handlers API) ?
• Quelles données lit‑il et écrit‑il (table users, table sessions, refresh tokens, rôles) ?
• Quelles pages ou endpoints en dépendent (admin, facturation, uploads, webhooks) ?
• Quels secrets et règles de validation sont impliqués (secret JWT, clés OAuth, hashing des mots de passe) ?

Pendant l'inventaire, signalez les risques de production visibles : secrets commis dans le repo, vérifications de tokens qui décodent mais ne vérifient jamais, SQL construit à partir de chaînes, et routes qui contournent les vérifications de permissions.

Comment choisir le système d'auth à conserver

L'objectif n'est pas de choisir le système "meilleur" en théorie. C'est de choisir celui qui est le plus sûr en exploitation, le plus facile à maintenir et le moins susceptible de vous surprendre à 2h du matin.

Commencez par vos priorités. Pour la plupart des équipes, la sécurité et la maintenabilité priment sur la commodité. Si personne dans l'équipe ne comprend un des systèmes, c'est un vrai risque même s'il semble raffiné.

Ensuite, confirmez quel système les vrais utilisateurs utilisent réellement. Ne vous fiez pas à l'UI. Vérifiez les logs de connexion, les écritures récentes dans les tables de sessions et les tickets support mentionnant « impossible de se connecter » ou « déconnecté encore ». Souvent un système gère la majorité du trafic alors que l'autre n'est utilisé que dans des flux marginaux.

Enfin, confirmez les fonctionnalités requises. Le système conservé doit supporter ce dont votre app a besoin aujourd'hui.

Checklist rapide de sélection

Conservez le système qui couvre vos indispensables avec le moins de code personnalisé :

• Méthodes de connexion nécessaires (email/mot de passe, magic links, social login, SSO)
• Rôles, équipes et permissions (si votre app en a)
• Defaults sécurisés (gestion des mots de passe, rotation de jetons, protection CSRF si besoin)
• Frontières claires dans le code (un seul endroit pour créer des sessions, un seul endroit pour vérifier l'auth)
• Débogage facile et messages d'erreur clairs

Si vous êtes bloqué, un critère pratique est les frontières et le modèle de données. L'option qui étale les vérifications d'auth sur des routes aléatoires, écrit dans plusieurs tables "au cas où" et crée des cookies supplémentaires continuera à causer des bugs.

Exemple : si un auth de framework gère de façon fiable les cookies de session, tandis qu'une connexion custom définit aussi son propre cookie et sa propre ligne de session, gardez l'auth du framework et migrez le flux custom dedans.

Comprendre vos utilisateurs, sessions et modèle de données avant de toucher au code

Avant de consolider quoi que ce soit, soyez clair sur ce que signifie "un utilisateur" dans votre app aujourd'hui. Deux systèmes d'auth créent souvent deux identités pour la même personne, et l'app bascule silencieusement entre elles. Sauter cette étape mène à des déconnexions aléatoires, des données manquantes et de la confusion de comptes.

Suivez comment un enregistrement utilisateur est créé et apparié. Les connexions sont‑elles liées à l'email, à un UUID interne, à un provider ID (Google/GitHub), ou à un mélange ? Cherchez les cas limites : changement d'email, différences de casse (User@ vs user@) et utilisateurs ayant créé deux comptes par différentes méthodes.

Vérifiez où résident réellement les mots de passe. Un système peut stocker les hashs de mot de passe dans une table users, tandis que l'autre n'a jamais stocké de mots de passe (par ex. login social uniquement). Ne supposez pas que vous pouvez "déplacer les mots de passe" entre systèmes. Dans la plupart des cas vous ne pouvez pas et ne devriez pas.

Puis cartographiez les sessions de bout en bout : ce qui est défini dans le navigateur, ce qui est stocké côté serveur et ce que l'app vérifie à chaque requête. Il est courant de trouver plusieurs types de session actifs en même temps.

Rédigez un snapshot d'une page :

• Identifiants utilisateur : colonnes et règles utilisées pour associer les comptes
• Méthodes d'auth activées : mot de passe, magic link, providers OAuth
• Mécanisme de session : cookies, sessions sauvegardées en BD, JWT, refresh tokens
• Où l'état de session est stocké : tables, cache, localStorage
• Tables en double : deux tables users, deux tables sessions, tables de profil "shadow"

Regardez aussi les duplicatas « inoffensifs » qui ne le sont pas, comme une table profiles qui est la source réelle des permissions ou du statut d'abonnement.

Concevoir la migration pour que les comptes existants continuent de fonctionner

L'état cible est une source de vérité pour l'identité (qui est l'utilisateur) et l'autorisation (ce qu'il peut faire). Tout le reste devient une couche de compatibilité que vous pourrez retirer plus tard.

Décidez quel enregistrement utilisateur sera réel. Cet enregistrement doit posséder l'ID utilisateur canonique, l'email et les champs rôle/permission. Ensuite, faites en sorte que chaque chemin de connexion atterrisse sur ce même ID utilisateur, même si la requête démarre dans le système legacy.

Si les systèmes utilisent des IDs différents, créez un mapping. L'approche la plus sûre est un pont explicite : stocker l'ancien ID sur l'enregistrement conservé, ou ajouter une petite table de mapping. Évitez de réécrire les IDs en place si ils sont référencés dans de nombreuses tables.

Les mots de passe sont l'endroit où les migrations cassent le plus souvent les utilisateurs. Si vous pouvez réutiliser les hashs de mot de passe en toute sécurité, copiez le hash plus les métadonnées nécessaires (algorithme, sel, facteurs de coût) et conservez l'ancien vérificateur pendant un moment. N'obligez les réinitialisations que lorsque vous ne pouvez vraiment pas valider les anciens hashs, ou quand un problème de sécurité l'exige.

Définissez des politiques pour les cas limites avant de commencer :

• Emails dupliqués : choisissez un gagnant selon la dernière connexion ou l'email vérifié, et placez l'autre en quarantaine.
• Profils manquants : créez des profils minimaux au premier login réussi.
• Utilisateurs de test et données seed : marquez‑les et excluez‑les des comptes migrés.
• Sessions orphelines : expirez‑les en toute sécurité plutôt que d'essayer de les « réparer ».

Exemple : si vous avez l'auth du framework plus une connexion custom, gardez la table users du framework et importez les utilisateurs custom avec un champ old_id. Les utilisateurs continuent de se connecter et vous retirez progressivement le chemin custom.

Plan de déploiement étape par étape qui évite les déconnexions massives

Le chemin le plus sûr est un chevauchement court où l'app peut lire les deux systèmes, puis un arrêt contrôlé des écritures dans l'ancien. Vous voulez que les sessions existantes continuent de fonctionner pendant que les nouvelles connexions sont créées dans la nouvelle source de vérité.

Commencez par les bords : middleware qui lit les cookies, gardes auth API et code de recherche de session. C'est là que les déconnexions surprises apparaissent généralement.

Un déroulé pratique :

• Phase 1 (compat) : acceptez les deux formats token/cookie et mappez les deux au même ID utilisateur interne.
• Phase 2 (migration silencieuse) : quand une requête arrive avec une ancienne session, réémettez une nouvelle session et placez le nouveau cookie en plus de l'ancien.
• Phase 3 (basculement d'écriture) : créez désormais les nouvelles sessions seulement dans le système conservé. Arrêtez d'écrire dans l'ancienne table de sessions et cessez de définir l'ancien cookie au login.
• Phase 4 (nettoyage) : après une date de coupure claire et la surveillance, supprimez les anciens chemins de code, cookies et tables.

Entre les phases, surveillez les signaux réels avant d'avancer : taux de succès de connexion, pics de 401/403, erreurs "user not found" et tickets support concernant des déconnexions. Si quelque chose saute, revenez en arrière sur le basculement d'écriture (Phase 3) avant de retirer la compatibilité en lecture (Phase 1).

Exemple : si l'app définit à la fois un cookie de framework et un JWT custom, continuez à lire les deux pendant une à deux semaines, mais ne générer que le cookie du framework après le switch.

Cookies et jetons : supprimer les extras sans casser les sessions

Les cookies et jetons sont les premiers responsables des échecs de consolidation. Un système peut utiliser un cookie de session signé, tandis que l'autre utilise un JWT plus un refresh token. Les utilisateurs se retrouvent connectés d'un côté et déconnectés de l'autre.

Commencez par lister chaque cookie et jeton lié à l'auth que votre app pose, et où il est posé. Incluez middleware serveur, code client et helpers du framework. C'est la seule manière sûre de supprimer des cookies d'auth en double.

Inventoriez l'essentiel :

• Nom du cookie et but (session, refresh, CSRF, "remember me")
• Qui le pose (route serveur, code client, plugin framework)
• Scope (domain, path, SameSite, Secure, HttpOnly)
• Comment il est validé (clé de signature, clé de chiffrement, secret du token)
• Où il est lu (API, pages SSR, middleware edge)

Les collisions de cookies sont un problème caché courant. Deux systèmes peuvent réutiliser le même nom de cookie avec des clés de signature différentes, ou poser des cookies à des scopes différents (app.example.com vs example.com). Cela peut provoquer des déconnexions aléatoires, des boucles de redirection infinies ou des utilisateurs authentifiés avec la mauvaise session.

Si vous trouvez une collision, prévoyez un renommage propre plutôt que d'essayer de faire marcher les deux pour toujours. Introduisez un nouveau nom de cookie pour le système que vous gardez, acceptez les deux brièvement, puis retirez l'ancien cookie.

La déconnexion nécessite une attention particulière pendant le chevauchement. Les utilisateurs cliqueront sur "se déconnecter" une fois et s'attendront à ce que tout disparaisse. Pendant la migration, faites en sorte que la déconnexion supprime à la fois les anciens et nouveaux cookies (et révoque côté serveur les tokens si vous utilisez des refresh tokens). Sinon vous risquez un login fantôme où l'ancien cookie les reconnecte immédiatement.

Exemple : un outil IA a ajouté des sessions NextAuth et un cookie JWT custom appelé auth. Si les deux existent, votre serveur peut accepter NextAuth tandis que le client continue d'envoyer le JWT. Choisissez-en un, renommez le cookie conservé si nécessaire, et ajoutez un pont temporaire qui transforme un ancien cookie valide en nouvelle session.

Nettoyage de la base : sessions, utilisateurs et tables d'auth restantes

Les erreurs en base transforment la consolidation en déconnexions massives ou en failles de sécurité. Traitez le nettoyage comme une migration, pas comme un bouton supprimer.

Cartographiez chaque table liée à l'auth et décidez ce qu'il en advient :

• Conserver : utilisée activement par le système choisi (users, sessions, refresh tokens)
• Fusionner : contient des données utilisateurs réelles qu'il faut importer (profiles, emails, hashs de mot de passe)
• Archiver : utile pour le support et le rollback (sessions legacy, comptes legacy)
• Supprimer : vraiment inutilisée après validation

Avant d'agir en production, écrivez des migrations réversibles. Au lieu de supprimer des lignes legacy de sessions, copiez‑les dans une table d'archive avec un timestamp, puis changez l'app pour qu'elle cesse de lire la table legacy.

Rendre les références ennuyeuses (et correctes)

Les données d'auth ne sont pas isolées. Rôles, appartenances d'org, permissions et logs d'audit pointent souvent vers un ID utilisateur précis. Si le nouvel auth utilise des IDs différents, vous avez besoin d'un plan de traduction clair.

Une approche simple est d'ajouter un champ de mapping stable (comme legacy_user_id) sur la table utilisateur conservée, migrer les utilisateurs, puis mettre à jour les références par petits lots. Faites pareil pour les sessions : si vous aviez sessions et user_sessions, choisissez une source de vérité et adaptez le code.

Séquence de déploiement qui réduit les surprises :

• Backfill des nouvelles tables et colonnes de mapping sans changer le comportement.
• Mettre à jour l'app pour lire depuis la nouvelle source tout en écrivant brièvement dans les deux.
• Vérifier que rôles/orgs/permissions correspondent pour des comptes réels (admins inclus).
• Basculez les écritures vers les tables conservées uniquement.
• Archivez, puis supprimez les tables legacy après une période de refroidissement.

Confirmez aussi que rien ne touche encore les anciennes tables : jobs en arrière‑plan, dashboards admin, scripts analytics, outils support et tâches cron. C'est un endroit courant où un second chemin d'auth se cache.

Erreurs courantes qui déconnectent les utilisateurs ou ouvrent des failles

La façon la plus rapide de générer une vague de tickets support est de supprimer des pièces anciennes avant que le nouveau chemin ne gère tous les flux utilisateurs réels. L'app peut sembler correcte dans votre navigateur, mais les utilisateurs en production ont des cookies plus anciens, des sessions à moitié expirées et des liens favoris.

Erreurs qui causent des déconnexions massives ou des failles :

• Désactiver trop tôt le vieux middleware d'auth, de sorte que les sessions existantes ne soient plus reconnues.
• Changer les routes de reset ou de vérification en plein milieu de la migration, ce qui casse des emails déjà envoyés ou vérifie le mauvais compte.
• Laisser des vérifications de tokens trop permissives (accepter des tokens sans vérification complète, sauter les checks issuer/audience, ou ne pas expirer les sessions).
• Oublier d'autres clients (apps mobiles, outils admin, jobs en arrière‑plan, webhooks entrants) qui envoient encore l'ancien cookie ou token.
• Ne pas tester le comportement des cookies entre sous‑domaines et environnements (localhost vs staging vs prod), ce qui fait tomber des cookies à cause des flags domain, SameSite ou Secure.

Un exemple concret : vous supprimez l'ancien cookie de session parce que le nouveau système utilise des JWT, mais un outil admin embarqué sur admin.yoursite.com ne connaît que le cookie de session. Il casse, et quelqu'un « répare » en désactivant les checks auth sur cette route. C'est comme ça que les migrations créent des failles de sécurité.

Deux mesures de sécurité réduisent le risque :

• Gardez brièvement actifs les deux validateurs et loggez lequel a été utilisé par requête.
• Figiez les chemins URL pour les liens de reset/verify jusqu'à ce que les anciens emails aient expiré et que les redirections soient confirmées.

Vérifications rapides à exécuter avant et après le déploiement

Le nettoyage le plus sûr est celui que vous pouvez annuler rapidement. Les changements de code sont seulement la moitié du risque. L'autre moitié est ce qui se passe dans de vrais navigateurs avec des cookies anciens et des sessions à moitié expirées.

Avant la mise en production, confirmez :

• L'inventaire est complet : chaque nom de cookie, header token, store de session et table liée à l'auth est documenté.
• Un système est la source de vérité pour l'identité et les rôles, et toutes les routes le lisent.
• Les noms et scopes de cookies sont confirmés (domain, path, SameSite, Secure), avec un plan pour ignorer ou remplacer les anciens cookies.
• Un plan de rollback existe et est à un deploy près (par ex. un feature flag qui réactive l'ancien check de session).
• Votre matrice de tests est écrite et exécutée pour signup, login, logout, reset de mot de passe et vérifications de rôle/permission.

Ne vous fiez pas à un seul compte happy‑path. Testez au moins un utilisateur créé sous chaque ancien système, plus un utilisateur « messy » avec les deux cookies définis. C'est là que les bugs se cachent.

Après le déploiement, surveillez le comportement plus que le code :

• Surveillez les échecs de connexion par raison (token invalide, session manquante, CSRF mismatch, rôle refusé), pas seulement le nombre total.
• Suivez le taux de création de sessions et comparez‑le au trafic normal.
• Confirmez que la table de sessions legacy et les tables d'auth legacy ne reçoivent plus d'écritures après le cutover.
• Vérifiez manuellement des flux dans une fenêtre incognito et dans un navigateur sale qui a encore des cookies anciens.
• Quand tout est stable, retirez les anciens secrets et clés, supprimez les anciennes sessions, puis seulement ensuite droppez les tables restantes.

Un exemple réaliste : fusionner un auth de framework avec une connexion custom

Une situation courante créée par l'IA ressemble à ceci : l'UI utilise NextAuth (cookies, callbacks, une table sessions), puis quelqu'un ajoute plus tard une connexion JWT custom "juste pour l'API". Vous avez maintenant deux sources de vérité sur qui est l'utilisateur.

Les symptômes sont confus. Un utilisateur peut se connecter et naviguer l'UI, mais les appels API renvoient 401 car ils attendent un Bearer token. Ou l'API fonctionne dans Postman avec un JWT, mais l'UI renvoie sans cesse vers la page de connexion car la session cookie manque. Pire, le même e‑mail peut aboutir à deux IDs utilisateurs différents selon le chemin qui a créé le compte.

La réparation la plus sûre est de choisir un gagnant et de migrer sans forcer tout le monde à se réinscrire. Si vous consolidez vers NextAuth, gardez le chemin JWT custom brièvement comme couche de compatibilité.

Migration pratique :

• Choisissez l'ID utilisateur réel (souvent la table users de NextAuth) et mappez les utilisateurs JWT‑only vers cet ID.
• Acceptez temporairement les deux : autorisez les requêtes API via cookie de session ou via l'ancien JWT, mais résolvez les deux en un ID utilisateur unique côté serveur.
• Quand les utilisateurs se reconnectent (ou rafraîchissent), émettez uniquement la méthode de session conservée et cessez de mint des JWT.
• Après une courte fenêtre, retirez la vérification JWT, supprimez le cookie en double et retirez les tables de sessions/token inutilisées.

Un nettoyage sûr se termine avec un seul cookie, un seul store de sessions et un seul ID utilisateur utilisé partout.

Prochaines étapes : quand demander de l'aide

Si vous ne pouvez pas expliquer en une phrase comment une requête devient un utilisateur authentifié dans votre app, marquez‑l. Ces changements semblent petits, mais peuvent verrouiller des gens ou affaiblir la sécurité en silence.

Signes qu'il faut s'arrêter et demander un second avis

Vous êtes probablement au‑delà d'un simple "nettoyage" et dans un projet de "migration" si :

• Vous ne pouvez pas mapper chaque utilisateur à une identité unique (deux tables users, emails décalés, IDs dupliqués).
• Vous ne savez pas comment les mots de passe sont hachés (ou vous voyez plus d'une méthode de hashing).
• Les vérifications de rôle sont mixtes (certaines routes utilisent du middleware, d'autres vérifient un cookie custom, d'autres interrogent la DB).
• Sessions et cookies se chevauchent (les utilisateurs semblent connectés mais les appels API échouent ou l'identité bascule).

Ce qu'il faut préparer pour une revue

Vous obtiendrez de meilleures réponses plus rapidement si vous rassemblez un petit paquet d'informations :

• Accès au repo (ou un export propre) plus la config de déploiement actuelle
• Liste des env vars liées à l'auth (noms de cookies, secrets JWT, IDs clients OAuth, URLs de callback)
• Un dump du schéma DB et les compteurs de lignes pour users, sessions et autres tables d'auth
• Logs récents autour des logins, refresh de tokens et erreurs non autorisées
• Une note courte sur ce que rapportent les utilisateurs (déconnexions forcées, mauvais comptes, accès admin cassé)

Si ce désordre a été créé par des outils IA et que vous avez besoin d'un plan de nettoyage sûr et orienté production, FixMyMess (fixmymess.ai) aide les équipes à diagnostiquer une authentification emmêlée, supprimer les cookies et chemins de session en double, et durcir le code avant que quoi que ce soit ne casse en production.