Quitter Auth0 : ce qui migre vraiment, et la seule chose qu'ils ne vous donneront pas

La plupart des équipes ne quittent pas Auth0 parce qu'elles le détestent. Elles partent parce que la facture a grimpé, ou parce que SAML et SCIM se sont révélés cachés derrière un palier entreprise facturé par connexion, et que le lien SSO de chaque nouveau client fait tourner le compteur. Puis elles envisagent de migrer pour de vrai leur fournisseur d'identité, jugent que ça a l'air terrifiant, et restent une année de plus.

C'est moins terrifiant qu'il n'y paraît. Voici ce qu'implique une vraie migration depuis Auth0 (les parties ennuyeuses, les parties délicates et l'unique partie réellement difficile) pour que vous puissiez en juger par vous-même.

Ce que contient votre locataire Auth0

Une poignée de choses doivent atterrir quelque part de nouveau :

• Applications → clients OAuth/OIDC. Callbacks, URL de déconnexion, origines autorisées, types d'autorisation et le secret client. Mécanique.
• API (serveurs de ressources) + scopes → audiences et scopes, reliés aux clients qui les utilisent (Auth0 suit cela sous le nom de « client grants »).
• Rôles et leurs attributions → rôles + liens de rôle par utilisateur.
• Connexions → connexions entreprise (OIDC/SAML), sociales et base de données. L'OIDC entreprise se mappe proprement sur un fournisseur fédéré ; le reste, vous le reconfigurez.
• Utilisateurs → profils, métadonnées et identités sociales/entreprise liées.

Rien de tout cela n'est difficile en principe. La nervosité vient de trois choses précises.

Les trois choses qui rendent les gens nerveux

1. Garder les identités stables. Vos utilisateurs sont référencés par leur sub (et vos applications par client_id) un peu partout : refresh tokens détenus par des applications en aval, lignes SCIM dans les IdP de vos clients, identifiants utilisateur stockés dans votre propre base de données. Si une migration génère de nouveaux identifiants, tout cela casse silencieusement. Le remède est simple à énoncer et essentiel à réussir : préserver le user_id d'Auth0 en tant que sub et conserver client_id à l'identique. Alors rien en aval ne s'en aperçoit.

2. Les mots de passe, la difficulté bien réelle. La Management API d'Auth0 ne renvoie jamais les hachages de mots de passe. C'est une politique délibérée d'Auth0, pas une lacune de votre outillage. Vous avez deux voies honnêtes :

• Demander l'export en masse assisté par le support d'Auth0, qui vous fournit un fichier NDJSON avec le hachage bcrypt de chaque utilisateur. bcrypt est portable : tout ce qui vérifie bcrypt peut reprendre ces hachages à l'identique, et vos utilisateurs ne réinitialisent rien.
• Ou bien ignorer complètement les hachages et faire définir un nouveau mot de passe à la première connexion par les utilisateurs. Rien n'est « perdu » (il n'y avait aucun hachage à transporter) mais c'est une étape visible pour vos utilisateurs.

Il n'existe aucune API en libre-service pour les hachages. Quiconque vous affirme qu'un export Auth0 en un clic inclut les mots de passe sans ce fichier du support raconte n'importe quoi.

3. Le plafond des 1 000 utilisateurs. L'API de listage des utilisateurs d'Auth0 renvoie au maximum 1 000 utilisateurs. Pour un locataire plus grand, le fichier d'export en masse (le même que celui qui porte les hachages) est la source réelle et complète des utilisateurs, et non l'API en direct.

En faire un seul clic

Voilà ce que nous avons intégré à Authagonal. Vous pointez l'importateur vers une application machine-to-machine Auth0 (scopes en lecture seule), et il :

• Exécute d'abord un aperçu en lecture seule : il compte chaque application, API, rôle, connexion et utilisateur qu'il importera et signale tout ce qui mérite votre attention. Rien n'est écrit tant que vous ne validez pas.
• Fait migrer les applications, les scopes/audiences d'API, les rôles + attributions, les utilisateurs + métadonnées et les connexions OIDC entreprise, en préservant sub et client_id pour que les tokens et références existants continuent de se résoudre.
• Re-hache les secrets clients d'Auth0 (lisibles en clair) afin que vos applications continuent de s'authentifier sans rotation.
• Importe les hachages de mots de passe bcrypt à l'identique si vous fournissez le fichier d'export, et ce fichier lève aussi le plafond des 1 000 utilisateurs. Pas d'export ? Les utilisateurs définissent un mot de passe à la première connexion.

Et comme les fonctionnalités entreprise (SAML, SCIM, MFA, journaux d'audit, domaines personnalisés) sont incluses dans chaque forfait plutôt que facturées par connexion, ce qui vous a poussé vers la sortie ne vous attend pas de l'autre côté.

Une parenthèse sur les tests de migration

Nous testons l'importateur contre une base de données réelle et préremplie, pas contre des mocks, et ça a payé. ASP.NET Identity stocke LockoutEnd en tant que datetimeoffset, et le lire avec GetDateTime() lève une exception sur ce type. Un seul utilisateur verrouillé aurait fait échouer un import entier. On n'attrape ça qu'en exécutant le vrai importateur contre de vraies données. Si vous évaluez un outil de migration, demandez comment il est testé : « on mocke l'API source » n'est pas la même chose que « on l'exécute contre un locataire peuplé ».

Si vous lorgnez vers la sortie

La migration est plus ennuyeuse que vous ne le craignez (prévisualisez-la, gardez vos identifiants, choisissez votre voie pour les mots de passe) la seule vraie contrainte étant l'export des hachages d'Auth0. Si vous voulez voir ce qui migrerait depuis votre locataire, l'aperçu est en lecture seule et vous montre tout avant que vous ne validiez.

→ Migrer depuis Auth0