Migrer d’Auth0 vers FoxIDs

Transférez les connexions d’Auth0 vers FoxIDs en choisissant l’approche adaptée à chaque connexion. Importez les utilisateurs de base de données avec leurs hachages de mots de passe bcrypt ou laissez-les choisir un nouveau mot de passe. Importez les utilisateurs sans mot de passe et activez les codes à usage unique. Pour les connexions sociales et d’entreprise, configurez des méthodes d’authentification FoxIDs faisant confiance aux fournisseurs d’identité externes.

Ce guide technique couvre la configuration des applications, l’import des utilisateurs et la correspondance des comptes pour les connexions Auth0 de base de données, sans mot de passe par e-mail/SMS, sociales et d’entreprise.

Pour les utilisateurs de base de données et sans mot de passe, convertissez l’export Auth0 vérifié en fichier CSV et utilisez le FoxIDs Seed Tool pour charger les utilisateurs en masse dans FoxIDs. Les exemples CSV ci-dessous présentent les champs de chaque approche de migration.

Choisissez une méthode pour chaque groupe avant de préparer l’import :

Les utilisateurs importés avec ou sans mot de passe s’authentifient localement dans FoxIDs. Les utilisateurs des connexions sociales et d’entreprise s’authentifient auprès du fournisseur d’identité connecté.

Préparer la destination et l’application

Un environnement de test dédié permet d’essayer la migration avec un petit groupe d’utilisateurs avant le passage en production. Les étapes de configuration sont les suivantes :

1. Si vous souhaitez un domaine personnalisé, configurez-le et vérifiez-le sur le locataire avant de configurer les applications et les fournisseurs d’identité externes. Utilisez les URL FoxIDs obtenues tout au long de la migration. Une modification ultérieure du domaine nécessite de mettre à jour les configurations externes, notamment les URL d’autorité ou de métadonnées des applications ainsi que les URL de rappel et de déconnexion des fournisseurs.
2. Chaque environnement possède une méthode d’authentification Login par défaut nommée login. Personnalisez son identité visuelle et son interface de connexion pour obtenir l’apparence souhaitée et ajustez ses options de connexion aux utilisateurs importés.
3. Créez les méthodes d’authentification qui relient les utilisateurs sociaux et d’entreprise à leurs fournisseurs d’identité externes, conformément à la section de migration correspondante ci-dessous.
4. Configurez l’application, ses URL de redirection autorisées, son comportement de déconnexion et les API qui acceptent ses jetons d’accès.

FoxIDs Cloud assure l’envoi d’e-mails et de SMS pour la création de mots de passe, la connexion sans mot de passe et l’authentification multifacteur (MFA), selon l’offre FoxIDs Cloud choisie.

Configurez les paramètres MFA requis et les modalités d’inscription des utilisateurs ; les imports décrits ici ne transfèrent pas les inscriptions MFA d’Auth0. Pour les comptes avec mot de passe, examinez les exigences de longueur, de complexité et d’expiration : l’import d’un hachage ignore la validation de la politique de mots de passe pendant l’import, mais la politique choisie s’applique à la connexion.

La configuration des applications constitue un chantier distinct de l’import des utilisateurs. Examinez l’émetteur, l’audience, les portées, les revendications et la validation des jetons, ainsi que les hypothèses du SDK Auth0, les Actions, les appartenances aux organisations et les attributions de rôles. Réimplémentez le comportement nécessaire à l’application. Le guide général de migration couvre l’inventaire global des applications et les étapes de déploiement.

Exporter un groupe défini d’utilisateurs Auth0

Suivez les instructions d’export en masse des utilisateurs Auth0. Sélectionnez explicitement la connexion source avec connection_id ; sans ce champ, un export API inclut toutes les connexions. Gardez les utilisateurs de base de données, sans mot de passe et fédérés distincts pendant la conversion.

Utilisez un export compatible JSON (NDJSON) comme source de conversion. Les exports CSV d’Auth0 appliquent un échappement supplémentaire et ne constituent donc pas une entrée prête à l’emploi pour le FoxIDs Seed Tool. Un petit export permet d’essayer la conversion au format CSV du Seed Tool.

Incluez user_id, blocked ainsi que les identifiants et l’état de vérification utilisés par chaque connexion : email et email_verified, ou phone_number et phone_verified pour les utilisateurs SMS. Pour les comptes sociaux, d’entreprise et liés, conservez le fournisseur, la connexion et l’identifiant utilisateur de identities pour la correspondance des comptes. Exportez uniquement les données nécessaires après la migration et conservez le locataire et la connexion sources avec l’export. Consultez le schéma de profil utilisateur Auth0 pour sélectionner les champs.

Obtenir les hachages pour conserver les mots de passe

Demandez l’export des hachages de mots de passe au support Auth0. Il est distinct de l’export des données utilisateur. Le guide d’export des hachages d’Auth0 décrit les enregistrements NDJSON et le champ passwordHash. L’exemple $2b$10$... identifie la variante bcrypt 2b et le coût 10.

Associez chaque hachage au bon utilisateur à l’aide du locataire source, de la connexion de base de données et de l’identifiant utilisateur.

Mapper les données utilisateur et préserver les comptes applicatifs

FoxIDs crée son propre identifiant utilisateur persistant pour les utilisateurs locaux importés. Importer un user_id Auth0 comme revendication personnalisée n’en fait pas l’identifiant utilisateur FoxIDs et ne préserve pas automatiquement la revendication sub de l’application. Pour les connexions sociales et d’entreprise, vérifiez l’identité reçue directement du fournisseur et le sujet émis par FoxIDs vers l’application.

Pour conserver l’identifiant utilisateur Auth0 comme sub de l’application, importez-le dans une revendication personnalisée telle que legacy_auth0_user_id. Sur la méthode d’authentification Login, configurez une transformation de revendications Map avec l’action Replace claim, la revendication d’entrée legacy_auth0_user_id et la revendication de sortie sub. L’application reçoit alors l’identifiant utilisateur Auth0 comme sub, tandis que l’identifiant FoxIDs persistant de l’utilisateur reste inchangé.

Maintenez une correspondance entre l’identité source, la nouvelle identité FoxIDs et le compte applicatif existant. Par exemple, pendant la transition, l’ancienne identité Auth0 et la nouvelle identité FoxIDs doivent toutes deux désigner le même dossier client, sans créer deux dossiers. Vérifiez le sujet réellement émis vers chaque application et mettez sa correspondance de comptes à jour si nécessaire. Ne liez pas des comptes uniquement parce que leurs adresses e-mail correspondent.

Pour l’import des utilisateurs locaux, utilisez la correspondance suivante :

Migrer les connexions sociales et d’entreprise

Créez une méthode d’authentification FoxIDs pour chaque connexion sociale ou d’entreprise, avec une relation de confiance directe envers le fournisseur d’identité externe. Les utilisateurs conservent leurs comptes et leurs identifiants de connexion chez ce fournisseur.

1. Identifiez le fournisseur et la configuration de chaque connexion Auth0. Utilisez le guide d’intégration du fournisseur approprié, par exemple Google, Facebook ou Microsoft Entra ID, et sélectionnez la méthode d’authentification OpenID Connect, SAML 2.0 ou WS-Federation prise en charge.
2. Enregistrez ou configurez FoxIDs chez le fournisseur. Échangez les paramètres client ou les métadonnées de fédération et configurez les URL de rappel et de déconnexion indiquées dans le guide d’intégration. Conservez la configuration Auth0 pendant la transition.
3. Autorisez la nouvelle méthode d’authentification sur l’application FoxIDs. Configurez Home Realm Discovery pour que les utilisateurs puissent sélectionner leur fournisseur ou y être dirigés par les règles configurées.
4. Rapprochez l’identité du fournisseur du compte applicatif existant. Les identifiants renvoyés lors d’une connexion de test peuvent être comparés au compte source ; un identifiant utilisateur Auth0 n’est pas nécessairement celui renvoyé directement à FoxIDs. Si vous devez stocker dans FoxIDs des revendications ou des attributions d’accès par utilisateur, configurez et provisionnez des utilisateurs externes.
5. Recréez les restrictions auparavant appliquées par Auth0, notamment les utilisateurs bloqués et l’accès aux organisations.

Le flux attendu est application → FoxIDs → fournisseur d’identité externe → FoxIDs → application. FoxIDs émet les jetons de l’application après l’authentification de l’utilisateur par le fournisseur.

Vous pouvez essayer chaque connexion en démarrant la connexion depuis l’application, en sélectionnant le fournisseur et en terminant son parcours de connexion. Vous pouvez ainsi observer la MFA, le compte et les autorisations dans l’application, ainsi que la déconnexion.

Migrer les utilisateurs sans mot de passe

Importez les utilisateurs des connexions sans mot de passe par e-mail ou SMS d’Auth0 comme utilisateurs internes FoxIDs sans mot de passe. Configurez la connexion sans mot de passe pour qu’ils continuent à se connecter avec un code à usage unique. Les utilisateurs qui recevaient un lien magique Auth0 saisissent à la place un code à usage unique sur la page de connexion déjà ouverte. Ils n’ont ainsi pas à suivre de liens de connexion dans des e-mails ou SMS.

1. Activez l’e-mail ou le téléphone comme identifiant de connexion sur la méthode d’authentification FoxIDs Login, et activez Passwordless with email (one-time password) ou Passwordless with SMS (one-time password) selon le cas.
2. Pour une méthode de connexion dédiée aux utilisateurs sans mot de passe, sélectionnez Disable password authentication et désactivez la création/réinitialisation du mot de passe par e-mail et SMS. Le parcours de connexion reste ainsi centré sur les codes à usage unique.
3. Importez les utilisateurs en omettant Password et tous les champs de hachage de mot de passe. Laissez SetPasswordEmail, SetPasswordSms et ChangePassword à false pour ne pas leur imposer de choisir un mot de passe. Préservez l’état de vérification, l’état de désactivation et les revendications requises.

Pour essayer la connexion sans mot de passe, vous pouvez démarrer une connexion avec l’adresse e-mail ou le numéro de téléphone d’un utilisateur de test importé et saisir le code reçu. Un code valide permet à un utilisateur activé de poursuivre vers l’application après la MFA requise ; les codes invalides ou expirés et les comptes désactivés n’accordent aucun accès.

Par exemple, ce CSV du Seed Tool importe un utilisateur fictif avec connexion sans mot de passe par e-mail :

Email;EmailVerified;SetPasswordEmail;SetPasswordSms;ChangePassword;DisableAccount
alice@example.com;true;false;false;false;false

Pour les utilisateurs SMS, remplacez Email et EmailVerified par Phone et PhoneVerified, avec le numéro et l’état de vérification examinés. La même procédure de chargement s’applique. L’utilisateur reste sans mot de passe après une connexion sans mot de passe réussie.

Importer des utilisateurs avec des hachages de mots de passe bcrypt

FoxIDs accepte les chaînes bcrypt complètes avec les préfixes $2a$, $2b$ ou $2y$ et des coûts de 4 à 16. Pour les utilisateurs dont les hachages ne correspondent pas au format pris en charge, utilisez la création du mot de passe par e-mail.

Activez la connexion par e-mail et l’authentification par mot de passe sur la méthode d’authentification FoxIDs Login pour ces utilisateurs.

Copiez chaque valeur Auth0 passwordHash correspondante dans la colonne CSV PasswordHash et définissez PasswordHashAlgorithm sur bcrypt. Préservez la chaîne complète, avec sa variante, son coût et son sel intégré. Elle est déjà encodée pour bcrypt. Consultez les formats de hachage de mots de passe et le contrat d’import de mots de passe de la Control API.

Pour le Seed Tool, utilisez les colonnes suivantes. Il s’agit d’un compte de test synthétique ; remplacez-le par votre export vérifié :

Email;EmailVerified;PasswordHashAlgorithm;PasswordHash;SetPasswordEmail;ChangePassword;DisableAccount
alice@example.com;true;bcrypt;$2b$10$..CA.uOD/eaGAOmJB.yMBu3YunYvFEoaS5IJZ/wiqfQ/EWx.HaqjC;false;false;false

Omettez Password et PasswordHashSalt. Laissez SetPasswordEmail, SetPasswordSms et ChangePassword à false si l’utilisateur doit conserver son mot de passe existant. Préservez l’état de désactivation, l’état de vérification, les revendications et les exigences MFA de la correspondance vérifiée. Incluez PasswordLastChanged si vous connaissez la date de modification d’origine, en secondes Unix ; sinon, FoxIDs enregistre l’heure d’import pour les contrôles d’ancienneté du mot de passe.

La même procédure de chargement s’applique à tous les imports d’utilisateurs locaux. Le provisionnement en masse peut remplacer un compte existant et ses identifiants, quel que soit le format de mot de passe choisi.

Avec un utilisateur de test importé, vous pouvez essayer la connexion avec le mot de passe d’origine, puis avec un mot de passe incorrect. Le mot de passe d’origine authentifie l’utilisateur conformément à la politique configurée et à la MFA ; un mot de passe incorrect ou un compte désactivé ne donne aucun accès. La modification et la récupération du mot de passe peuvent aussi être essayées via l’interface Login configurée.

Le hachage importé reste en bcrypt après la connexion. Un mot de passe défini ou modifié dans FoxIDs est stocké au format PBKDF2 par défaut de FoxIDs. L’historique des mots de passe continue d’empêcher leur réutilisation selon la politique choisie, y compris lorsqu’un ancien hachage bcrypt est conservé après une réinitialisation.

Importer les utilisateurs pour la création du mot de passe

Utilisez cette méthode pour les comptes qui choisiront un nouveau mot de passe plutôt que d’importer un hachage. Activez la connexion par e-mail, l’authentification par mot de passe et la création du mot de passe par e-mail sur la méthode d’authentification FoxIDs Login. Pour les utilisateurs qui doivent rester sans mot de passe, suivez Migrer les utilisateurs sans mot de passe.

L’import des utilisateurs prépare les comptes. La création du mot de passe intervient lorsque chaque utilisateur démarre une connexion, pas pendant l’import.

Convertissez les enregistrements vérifiés en fichier UTF-8 pour le FoxIDs Seed Tool. Les en-têtes sont sensibles à la casse et le séparateur est un point-virgule. Cet exemple contient des utilisateurs fictifs avec des adresses e-mail déjà vérifiées ; le second compte reste désactivé :

Email;EmailVerified;SetPasswordEmail;DisableAccount;RequireMultiFactor;Claims
alice@example.com;true;true;false;true;"[{""Claim"":""legacy_auth0_user_id"",""Values"":[""auth0|demo-001""]}]"
blocked@example.com;true;true;true;true;"[{""Claim"":""legacy_auth0_user_id"",""Values"":[""auth0|demo-002""]}]"

SetPasswordEmail=true sélectionne la création du mot de passe avec confirmation par e-mail. Omettez Password et toutes les colonnes de hachage. Ce flux ne nécessite ni mot de passe temporaire partagé ni ChangePassword. RequireMultiFactor=true est la politique choisie dans l’exemple et nécessite de configurer les méthodes MFA correspondantes.

Ne transmettez la revendication d’exemple legacy_auth0_user_id qu’aux applications qui en ont besoin, via leur traitement configuré des revendications.

Charger les utilisateurs et examiner le résultat

Utilisez cette procédure pour les utilisateurs avec des hachages bcrypt, les utilisateurs sans mot de passe et ceux qui choisiront un mot de passe à la première connexion, avec les champs adaptés à la méthode choisie.

Le Seed Tool sépare les champs par des points-virgules ; les champs entre guillemets ne peuvent pas contenir de points-virgules ou de sauts de ligne. Utilisez les opérations utilisateur de la Control API si vos valeurs nécessitent une représentation d’import plus riche.

1. Téléchargez et configurez le Seed Tool pour l’environnement prévu. Définissez SeedSettings.UsersSvcPath sur le fichier CSV converti.
2. Exécutez le Seed Tool et sélectionnez U pour charger les utilisateurs en masse.
3. Enregistrez les nouveaux identifiants utilisateur dans votre correspondance de migration.

Vous pouvez essayer le chargement avec un CSV de quelques utilisateurs dans un environnement de test. Le Seed Tool indique le nombre de réussites et d’échecs. Vous pouvez examiner les utilisateurs importés dans FoxIDs Control pour consulter leurs identifiants, leur état de désactivation, leurs revendications et leurs indicateurs de création de mot de passe.

Le Seed Tool utilise le provisionnement en masse, qui peut remplacer les utilisateurs existants plutôt que les fusionner de manière sûre. Vérifiez les collisions avant le chargement. Ne réexécutez pas le fichier complet après que des utilisateurs ont défini leur mot de passe ou obtenu un accès : le remplacement peut supprimer leurs identifiants et leur état et créer de nouveaux identifiants utilisateur. Rapprochez les résultats d’un import partiel avant de réessayer ; traitez les modifications ultérieures par des mises à jour utilisateur ciblées et vérifiées.

Création du mot de passe à la première connexion

Pour un utilisateur importé activé avec SetPasswordEmail=true, le flux attendu est le suivant :

1. L’utilisateur ouvre l’application et démarre une connexion via FoxIDs Login.
2. FoxIDs identifie l’utilisateur par son adresse e-mail et envoie un code de confirmation.
3. L’utilisateur soumet le code et un nouveau mot de passe conforme à la politique de FoxIDs.
4. FoxIDs vérifie l’adresse e-mail, enregistre le mot de passe et efface les indicateurs de création du mot de passe. La connexion passe par les étapes MFA requises avant le retour à l’application.

L’import d’un utilisateur n’envoie pas l’e-mail de création du mot de passe. Les connexions suivantes utilisent le nouveau mot de passe FoxIDs, pas l’ancien mot de passe Auth0. Si un utilisateur ne peut pas recevoir le code, utilisez un processus de récupération approuvé qui vérifie son identité.

Vous pouvez explorer le flux avec un utilisateur de test en suivant les étapes de connexion ci-dessus. Ces scénarios présentent les résultats attendus :

Déployer et conserver une possibilité de retour arrière

La migration peut être déployée par application ou groupe d’utilisateurs. Les utilisateurs peuvent continuer via leur URL d’application habituelle avec le flux configuré : mot de passe existant, création du mot de passe, code à usage unique ou fournisseur d’identité externe existant.

Avant chaque import en production, rapprochez les utilisateurs créés, modifiés, bloqués ou supprimés depuis l’export. Définissez un bref gel des modifications ou un autre processus de rapprochement contrôlé. N’écrasez pas les utilisateurs déjà migrés pour appliquer ces changements.

Surveillez la livraison des e-mails et SMS, les échecs de création du mot de passe, les échecs de connexion et les problèmes de correspondance des comptes. Pour les imports de hachages, tenez compte des modifications de mots de passe dans Auth0 après l’export afin que les utilisateurs n’arrivent pas avec un mot de passe différent du hachage importé. Le retour arrière dépend de la disponibilité de l’ancienne configuration Auth0. Vous pouvez essayer de la restaurer pour une application de test afin d’observer le retour au flux de connexion Auth0.

Un mot de passe défini dans FoxIDs n’est pas resynchronisé vers Auth0. Un retour arrière utilise donc les identifiants encore détenus par Auth0. Définissez comment les utilisateurs créés uniquement dans FoxIDs accéderont à Auth0 si un retour arrière est nécessaire. Pour les connexions sans mot de passe et fédérées, conservez les paramètres de livraison et les connexions aux fournisseurs Auth0 nécessaires pour restaurer le flux précédent. Retirez l’ancienne intégration et supprimez les exports conservés seulement après validation de l’accès aux comptes et du support opérationnel.

Documentation associée

• Vue d’ensemble de la migration
• Importer de nombreux utilisateurs
• Opérations utilisateur de la Control API
• Connexion et Home Realm Discovery
• Fournisseur de messagerie
• Applications