Migrer depuis Azure AD B2C sans export du mot de passe : migration paresseuse, reset en masse et MFA

Emmanuel Gautier · 5 septembre 2026

Azure AD B2C ne permet pas d’exporter les mots de passe des utilisateurs. Microsoft Entra ID non plus. Le Microsoft Graph API retourne les profils utilisateurs, leurs attributs, leurs appartenances aux groupes et leurs liens vers les fournisseurs d’identité — mais jamais le hash du mot de passe. Ce n’est pas une fonctionnalité manquante ni un trou dans l’API : c’est une limite de sécurité volontaire, qui s’applique que vous quittiez B2C à cause de son calendrier de retrait ou simplement parce que vous changez de fournisseur CIAM.

Cette contrainte structure entièrement la façon dont une migration B2C vers un autre CIAM doit être conçue. Cet article présente les deux patterns de migration réellement viables — migration paresseuse avec export final, et export en masse avec reset forcé — puis traite du point qui casse les deux si vous ne l’anticipez pas : l’authentification multi-facteurs (MFA).

Nous ferons référence aux endpoints Azure B2C et Microsoft Graph concernés, et décrirons les capacités attendues côté CIAM, sans dérouler de code d’implémentation complet — il s’agit d’un guide de patterns et de décision, pas d’un tutoriel lié à une stack spécifique.

Pourquoi le mot de passe ne peut pas être exporté

Les hash de mot de passe dans Azure AD B2C sont stockés avec le schéma de hachage interne de Microsoft et ne sont exposés par aucune API supportée — ni Microsoft Graph, ni l’ancien Azure AD Graph API, ni les outils d’export de tenant B2C. Cela vaut pour les comptes locaux (email/nom d’utilisateur + mot de passe), et c’est cohérent avec la façon dont pratiquement tous les fournisseurs d’identité majeurs traitent les données d’authentification : OIDC, SAML et SCIM standardisent tous l’échange de données d’identité, mais aucun ne standardise l’échange de credentials, car cela viderait de son sens le hachage à sens unique.

Conséquence pratique : tout plan de migration qui suppose « exporter les utilisateurs, puis les importer avec leur mot de passe existant » est irréalisable dès le départ. Il ne reste que deux stratégies crédibles.

Option 1 : migration paresseuse via les endpoints Azure B2C, avec export final

La migration paresseuse (parfois appelée « migrate on login ») évite de forcer chaque utilisateur à réinitialiser son mot de passe dès le premier jour. Les deux systèmes tournent en parallèle pendant une fenêtre de transition, et chaque utilisateur est migré individuellement lors de sa prochaine connexion.

Les endpoints concernés

Export des profils et attributs (sans credentials) :

• Microsoft Graph GET /users — récupère les attributs du profil utilisateur : nom affiché, email, attributs personnalisés extension_, références aux fournisseurs d’identité
• Microsoft Graph GET /users/{id}/identities — récupère les identités locales et fédérées liées (email/nom d’utilisateur, liens vers les IdP sociaux)
• b2cIdentityUserFlowAttributes — récupère les définitions de schéma d’attributs personnalisés configurés dans vos user flows B2C, nécessaires pour bien mapper ces attributs vers le schéma du CIAM cible

Aucun de ces endpoints ne retourne un mot de passe ou son hash, par conception.

Vérification des credentials à la connexion :

• Authorization Code flow contre les endpoints OIDC du tenant B2C (/oauth2/v2.0/authorize, /oauth2/v2.0/token) — la méthode standard, compatible MFA, pour confirmer qu’un mot de passe est correct, en faisant réellement compléter une connexion interactive à l’utilisateur face à B2C
• Resource Owner Password Credentials (ROPC) (/oauth2/v2.0/token avec grant_type=password) — une alternative legacy, non interactive, qui permet à votre backend de vérifier un mot de passe directement sans redirection. Cela ne fonctionne que pour les comptes sans MFA et sans politique de Conditional Access bloquant les flux non interactifs — détaillé dans la section MFA plus bas.

L’architecture

La migration fait tourner deux systèmes côte à côte pendant une période bornée :

1. Pré-provisionner des comptes coquilles (« shell accounts ») dans le CIAM cible via l’export de profils du Graph API — chaque utilisateur obtient un compte avec les bons attributs, le bon email, et un statut du type migration_pending, mais sans mot de passe utilisable pour l’instant.
2. Garder la couche d’authentification de l’application connectée aux deux systèmes. À la connexion, vérifier d’abord si le compte de l’utilisateur dans le CIAM cible a déjà terminé sa migration. Sinon, basculer sur la vérification contre B2C.
3. Vérifier les credentials contre B2C au moment de la connexion (auth code flow ou ROPC, selon le statut MFA).
4. En cas de vérification réussie, définir le mot de passe dans le CIAM cible et passer le statut du compte à migrated. À partir de là, cet utilisateur s’authentifie directement contre le nouveau CIAM — B2C ne fait plus partie de son parcours de connexion.
5. Suivre la couverture de migration dans le temps. Les utilisateurs actifs sont migrés naturellement en quelques jours ou semaines ; les utilisateurs inactifs ne passeront jamais par ce chemin — d’où l’étape 6.
6. Déclencher un export final une fois la couverture atteint un plateau — typiquement lorsque 70 à 90 % de vos utilisateurs actifs mensuels ont été migrés et que la courbe de progression s’est aplatie. À ce moment, effectuez un dernier export en masse via le Graph API pour tous ceux qui restent non migrés, importez leurs profils (toujours sans mot de passe) dans le CIAM cible, et forcez une réinitialisation de mot de passe spécifiquement pour cette cohorte restante.

Cela borne votre dépendance à l’ancien tenant : vous n’attendez pas indéfiniment 100 % de migration organique, et vous ne forcez pas un reset sur vos utilisateurs les plus actifs, qui sont justement les moins tolérants à cette friction.

Séquence : première connexion pendant la fenêtre de migration paresseuse

La phase d’export final

Une fois décidée la clôture de la fenêtre de migration paresseuse, l’étape restante est un export en masse classique — les mêmes appels Graph API (GET /users, GET /users/{id}/identities), exécutés une fois sur la cohorte restante. Il n’y a pas d’étape de vérification à la connexion pour ce groupe puisque, par définition, ces utilisateurs ne se sont pas connectés pendant la fenêtre de transition. Importez leurs profils dans le CIAM cible avec un mot de passe placeholder inutilisable, et redirigez-les vers un reset forcé à la prochaine connexion — ce qui correspond exactement à l’Option 2 ci-dessous, appliquée à une population plus restreinte et connue.

Option 2 : sans migration paresseuse — export en masse avec reset forcé

Si votre base d’utilisateurs actifs est faible par rapport au nombre total d’utilisateurs, si votre application ne tolère pas de faire tourner deux systèmes d’authentification en parallèle, ou si vous voulez simplement une date de bascule fixe, passez directement à cette option.

Les endpoints concernés

Seuls les endpoints d’export de profils/attributs sont nécessaires :

• Microsoft Graph GET /users
• Microsoft Graph GET /users/{id}/identities
• b2cIdentityUserFlowAttributes pour le mapping du schéma d’attributs personnalisés

Aucun endpoint d’authentification B2C n’est appelé à quelque moment que ce soit — puisqu’aucune vérification en direct contre B2C n’a lieu, ce chemin est totalement découplé de la stack d’authentification de B2C, y compris sa configuration MFA.

Séquence : export en masse et reset forcé

Quand ce compromis est le meilleur choix

• Votre base d’utilisateurs est en grande partie dormante, et le coût d’ingénierie d’un chemin de vérification double authentification pour une poignée d’utilisateurs actifs ne se justifie pas.
• Vous avez besoin d’une date de bascule fixe et auditable plutôt que d’une traîne de migration ouverte.
• Votre tenant B2C utilise fortement les politiques personnalisées (Identity Experience Framework), ce qui serait coûteux à maintenir en sécurité sur une fenêtre de migration paresseuse prolongée.
• Votre CIAM cible ou votre posture de conformité bénéficie d’un événement de reset de credentials généralisé — certaines organisations profitent délibérément d’une migration de plateforme pour renforcer leurs politiques de mot de passe.

Le coût, c’est la conversion : attendez-vous à ce qu’une part réelle des utilisateurs abandonne le parcours de reset plutôt que de le terminer, en particulier pour des produits à faible engagement. Prévoyez votre communication (email, bannières in-app, capacité support) en conséquence.

Comment gérer le MFA

Le MFA est le point qui complique les deux chemins de migration, et il mérite une analyse à part car il casse spécifiquement l’étape de vérification — pas l’étape d’export, qui reste inchangée dans les deux cas.

Pourquoi ROPC casse avec le MFA

Le grant ROPC (grant_type=password) est un aller-retour unique : nom d’utilisateur et mot de passe en entrée, un token en sortie. Il n’y a aucun canal dans cet échange pour un second facteur. Si l’utilisateur a un MFA enregistré, ou si une politique de Conditional Access du tenant exige le MFA pour les flux non interactifs ou d’authentification legacy, ROPC échoue purement et simplement — typiquement avec une erreur de type AADSTS50076 ou AADSTS50079 — plutôt que de demander le second facteur. La documentation de Microsoft est explicite : ROPC n’est pas compatible avec ces scénarios, et c’est également un flux que Microsoft restreint et déprécie progressivement sur l’ensemble de la stack Entra/Azure AD, indépendamment de B2C.

Segmentez vos utilisateurs avant de choisir une méthode de vérification

Avant de finaliser l’un ou l’autre chemin de migration, obtenez une vue factuelle de la couverture MFA via les endpoints de méthodes d’authentification et de reporting d’enregistrement des credentials du Graph API. Vous devez savoir, concrètement :

• Quelle proportion de vos utilisateurs actifs a réellement enregistré un MFA
• Si les politiques de Conditional Access imposent le MFA de façon universelle, ou seulement pour certaines applications, réseaux ou niveaux de risque
• Si certains de vos flux de connexion actuellement autorisés sont exemptés de ces politiques (une source fréquente de ROPC qui continue à fonctionner pour un sous-ensemble d’utilisateurs pourtant soumis au MFA)

Cette segmentation est l’input déterminant pour la suite de la conception — ne devinez pas la couverture MFA, mesurez-la.

Les deux chemins de vérification, selon le statut MFA

• Sans MFA imposé : ROPC est viable — un seul appel backend non interactif vérifie le mot de passe sans redirection visible pour l’utilisateur. C’est l’option la moins friction quand elle est disponible.
• Avec MFA imposé : redirigez l’utilisateur vers l’Authorization Code flow à la place — une redirection interactive complète vers la page de connexion hébergée de B2C, où l’utilisateur complète son challenge MFA existant exactement comme avant. Considérez la complétion réussie de ce flow comme votre signal de vérification, exactement comme un succès ROPC, puis procédez à la définition du mot de passe dans le CIAM cible.

Une variante plus simple, si l’UX de votre application tolère une redirection supplémentaire à la première connexion : utilisez l’Authorization Code flow de façon universelle, pour les utilisateurs MFA comme non-MFA. Cela contourne entièrement les restrictions et la trajectoire de dépréciation de ROPC, et vous donne un seul chemin de code de vérification au lieu de deux. La seule raison de conserver ROPC est si une vérification totalement silencieuse, sans redirection, compte pour l’UX du segment sans MFA.

L’enregistrement MFA ne se migre pas non plus

Un point facile à manquer : même pour les utilisateurs vérifiés et migrés avec succès, leur enregistrement MFA — secrets TOTP, numéros de téléphone enregistrés, credentials WebAuthn/passkey — ne se transfère pas vers le nouveau CIAM. Microsoft n’exporte pas plus ces données que les mots de passe, et même si c’était le cas, la plupart des CIAM cibles ne pourraient pas importer directement une seed TOTP ou un credential FIDO2 étranger. Budgétez le réenregistrement du MFA comme une étape obligatoire et distincte, immédiatement après la migration du mot de passe — pas quelque chose qui suit gratuitement. Marquer le compte migré comme « configuration MFA requise » à la prochaine connexion, avant d’accorder l’accès complet, est la façon la plus sûre de l’imposer plutôt que de la laisser optionnelle.

Résumé comparatif

Rappel sur la dépréciation d’Azure AD B2C

Cette question de migration devient de moins en moins optionnelle. Le calendrier publié par Microsoft :

• 1er mai 2025 — Fin de la vente. Les nouveaux clients ne peuvent plus acheter Azure AD B2C, et aucun nouveau tenant ne peut être créé en dehors des contrats existants.
• 15 mars 2026 — Azure AD B2C Premium P2 (Identity Protection) est retiré pour tous les clients, y compris les tenants existants.
• Au moins jusqu’à mai 2030 — Fin de support annoncée par Microsoft pour les tenants Azure AD B2C P1 restants. Les correctifs de sécurité et les SLA continuent jusque-là, mais la plateforme est en mode maintenance : aucune nouvelle fonctionnalité ne sera livrée.

Si vous n’avez pas encore décidé vers où migrer, consultez notre article associé sur les options après l’annonce de retrait d’Azure AD B2C pour une comparaison des fournisseurs. Cet article suppose cette décision déjà prise et se concentre spécifiquement sur la mécanique de migration des credentials, applicable quel que soit le CIAM choisi.

Conclusion

La contrainte de base — aucun export de mot de passe, jamais, chez aucun fournisseur d’identité majeur — implique que toute stratégie de migration doit substituer une étape de vérification à une étape d’export. La migration paresseuse vérifie à la connexion, au prix de faire tourner deux systèmes en parallèle. L’export en masse avec reset forcé supprime la vérification, au prix d’une friction universelle pour les utilisateurs. Le MFA ajoute une branche à chaque chemin choisi, et le réenregistrement reste un coût séparé dans tous les cas.

Rien de tout cela n’est spécifique à Azure B2C — le même pattern de comptes coquilles avec vérification à la connexion s’applique à toute migration CIAM vers CIAM où la plateforme source refuse (à juste titre) d’exporter les credentials. Le calendrier de retrait d’Azure AD B2C rend simplement cette problématique immédiate pour un grand nombre d’équipes en ce moment.