En réalité, la plupart des gens pensent qu'une identité se résume à un nom d'utilisateur et un mot de passe. Vous les saisissez, vous accédez au service et c'est tout. Mais quand vous êtes une entreprise au service de clients, l'identité devient bien plus complexe. Que se passe-t-il quand votre application doit permettre à des milliers de personnes de s'inscrire ? Ou de se connecter avec leur compte Google plutôt que de créer un énième mot de passe ? Et comment sécuriser toutes ces données clients sans les mélanger à l'annuaire de vos employés ? C'est précisément le problème que Microsoft Antra External ID a été conçu pour réseau. Voici le point important. Il remplace entièrement Azure AD B2C. A la fin de cet épisode, vous comprendrez ce qu'est réellement External ID, les trois façons principales de l'utiliser et pourquoi il est crucial pour toute application destinée aux clients. L'ancienne méthode, des silos d'identité séparés.

Imaginez qu'il y a 20 ans, vous ayez créé une application pour des clients. A l'époque, vous deviez concevoir votre propre système de connexion, coder la gestion des mots de passe, configurer une base de données, créer le flux de réinitialisation tout en partant de zéro. Cela fonctionnait pour une petite application avec quelques centaines d'utilisateurs, mais à mesure que les apps grandissaient, tout devenait vite compliqué. Les entreprises devaient permettre des connexions via Google ou Facebook, exiger l'authentification multifacteur et gérer des millions de comptes sans subir de pannes. Tout construire soi-même était devenu un cauchemar. La première réponse de Microsoft fut Azure AD B2C. C'est un service d'identité client qui, à l'époque, résolvait un vrai problème. Mais c'est là que les difficultés ont commencé. Le problème majeur résidait dans ce qu'on appelait les stratégies personnalisées, rédigées en XML, XML.

Si vous avez déjà travaillé sur des fichiers XML de plusieurs centaines de lignes, vous savez à quel point c'est pénible. C'est pénible. Difficile à configurer, difficile à déboguer, et en cas de panne, bon courage pour en trouver la cause. De plus, Azure AD B2C était séparé de la plateforme d'identité principale de Microsoft. Donc si vous utilisiez déjà Microsoft 365 ou Azure AD pour vos employés, B2C imposait l'apprentissage d'un tout nouveau produit. Comme on pouvait s'y attendre, les équipes IT peinaient à la maintenance, les développeurs redoutaient son usage, et les clients subissaient une expérience d'inscription maladroite qui les incitait à partir. Microsoft a compris qu'il fallait quelque chose de plus simple et unifié, et c'est devenu Microsoft Entra External ID. Ce qui est réellement Microsoft Entra External ID ? Alors qu'est-ce que Microsoft Entra External ID exactement ? Voici la définition la plus simple.

C'est un service d'identité cloud pour les utilisateurs externes, clients, partenaires et invités, et non pour les employés. Voyez les choses ainsi. Imaginez que votre entreprise possède un immeuble de B2. C'est votre tenant pour vos collaborateurs. C'est là que travaillent vos employés, où se trouve leur bureau et où leur badge leur permet d'entrer. Entra ID gère ce bâtiment. Maintenant imaginez que vous ouvriez une boutique pour les clients, un espace séparé, avec sa propre entrée, ses propres règles et sa propre sécurité. Les clients ne s'égarent pas dans la salle de poste des employés, et les employés n'accèdent pas accidentellement au compte client. C'est ça, External ID. Il fait partie de la famille Microsoft Entra, mais sous une forme différente. Il est conçu pour la sienne, la gestion des identités et des accès clients, et il gère tout le cycle de vie d'un utilisateur externe. Inscription, connexion, réinitialisation de mot de passe, gestion de profil, MFA, émission de jetons.

Il fonctionne avec des protocoles standards comme OOS 2.0, OpenID Connect et SAML, donc presque n'importe quelle application que vous créez peut s'y connecter. Mais voici la grande différence avec l'ancien Azure AD B2C. External ID est plus sain. Fini les politiques SAML personnalisées. Au lieu de cela, vous configurez les flux d'utilisateurs directement dans le centre d'administration. Bien, vous utilisez des extensions d'authentification personnalisées, qui s'intègrent à votre logique backend existante. Même puissance, moins de casse-tête. Les trois cas d'usage principaux. Alors, comment utilisez-vous réellement External ID ? Il existe trois scénarios principaux. Ils couvrent presque toutes les situations où vous devez gérer quelqu'un qui n'est pas un employé. Commençons par le plus courant, identité client ou B2C. Imaginez que vous créez une application de commande de pizza. Vous avez besoin que les gens s'inscrivent, passent des commandes et reviennent la semaine suivante.

Vous voulez qu'ils se connectent avec leur compte Google plutôt que de créer un nouveau mot de passe et vous devez recueillir. Leur nom, numéro de téléphone et préférence de livraison. External ID gère tout cela. Vous bénéficiez de flux d'inscriptions et de connexions préconstrées. Vous configurez les attributs à collecter, nom, téléphone, tout ce dont vous avez besoin. Vous configurez la connexion sociale avec Google, Facebook ou Apple. Et lorsqu'un utilisateur s'authentifie, External ID émet un jeton vers votre application pour qu'elle sache qui est cette personne. C'est le remplaçant d'Azure AD B2C et c'est là que la plupart des organisations commencent. Un autre scénario est la collaboration inter-entreprise ou B2B. C'est lorsque vous devez donner à des partenaires ou des fournisseurs accès à vos applications internes. Peut-être avez-vous un site SharePoint que votre partenaire logistique externe doit avoir ou un outil de gestion de projet que votre designer indépendant utilise.

Dans ce scénario, vous les invitez en tant qu'utilisateur invité dans votre locataire de travail. External ID gère l'email d'invitation, le processus d'acceptation où ils valident l'invitation et les politiques d'accès qui contrôlent ce qu'ils peuvent voir. Cela existe en fait depuis des années sous le nom de collaboration B2B au sein d'Azure AD. Mais désormais cela fait partie de l'offre External ID, vous gérez donc tout au même endroit qu'aux identités clients. Ensuite il y a le Machine to Machine ou M2M. Celui-ci est moins visible pour les utilisateurs finaux, mais tout aussi important. Parfois votre service back-end doit communiquer avec une autre API, un processeur de paiement, un service d'analyse de données ou un microservice interne ou un microservice interne. Aucune intervention humaine, c'est juste une application qui en appelle une autre. External ID utilise le flux OAuth 2.0 Client Credentials.

Votre service s'authentifie à l'aide d'un identifiant client et d'un secret et obtient un jeton pour appeler l'API en aval. Cela nécessite le module complémentaire M2M Premium, il y a donc un coût, mais pour sécuriser une communication API à API, c'est intégré. Ces trois scénarios couvrent presque toutes les situations d'identité externe que vous rencontrerez. Mais vous devez prendre une décision importante où ces utilisateurs vont-ils résider concrètement. Car External ID peut fonctionner dans deux environnements très différents. Le tenant Workforce et le tenant External. Analysons ces deux options. External ID peut fonctionner au sein de votre tenant Workforce existant ou comme un tenant external totalement séparé. Ce n'est pas la même chose. Et faire le mauvais choix peut poser problème par la suite. Commençons par l'option du tenant Workforce. Votre entreprise possède déjà un tenant Entra ID pour vos employés.

C'est votre tenant Workforce. Si vous activez l'inscription en libre-service des invités dans ce tenant, des utilisateurs externes peuvent s'inscrire et arriver dans le même répertoire que vos employés. Leur compte se retrouve juste à côté de celui de votre PDG. Pour des scénarios B2B simples, comme inviter quelques partenaires sur un site SharePoint, mélanger les comptes dans le même répertoire est parfaitement acceptable. C'est simple à mettre en place et vous n'avez pas besoin de gérer un tenant séparé. Mais attention, si vous créez une application client avec des milliers d'utilisateurs, vous ne voulez pas qu'il réside dans le même répertoire que vos employés. C'est un risque de sécurité. Un employé pourrait accéder accidentellement à des données clients. Un changement de configuration destiné aux employés pourrait affecter l'accès des clients. De plus, votre image de marque pour les pages de connexion client serait liée à celle de votre entreprise.

Ce n'est pas d'idéal. Alternative est l'option du tenant external. Vous créez un tout nouveau répertoire isolé dédié spécifiquement aux identités des clients. Aucun employé n'y réside. C'est un espace totalement distinct. Vous vous souvenez de l'analogie avec l'immeuble de bureau tout à l'heure ? Le tenant workforce est votre siège social. Le tenant external est la vitrine dédiée que vous ouvrez à vos clients. Ils ont leur propre entrée, leurs propres règles et leur propre sécurité. Rien n'est mélangé. Alors, quels sont les avantages d'un tenant external ? Tout d'abord, vous bénéficiez d'un répertoire d'utilisateurs isolés. Les données clients restent totalement séparées des données des employés, ce qui réduit les risques et simplifie la conformité. Deuxièmement, vous profitez d'une identité visuelle. Vous pouvez personnaliser l'apparence des pages de connexion spécifiquement pour vos clients sans rien modifier dans votre tenant d'entreprise.

Troisièmement, vous disposez d'une API d'authentification native pour les applications mobiles, vous permettant de créer des écrans de connexion entièrement personnalisés dans vos applications iOS ou Android. Fini les redirections vers le navigateur et les vues web peu ergonomiques. Et quatrièmement, vous bénéficiez d'une tarification basée sur le MAU, le nombre d'utilisateurs actifs mensuels. Vous ne payez que pour les utilisateurs qui s'authentifient réellement au cours d'un mois donné, ce qui évolue naturellement avec la croissance de votre clientèle. Alors, comment choisir entre les deux ? C'est assez simple. Si vous développez une application B2C avec des milliers de clients, optez pour un tenant externe. C'est l'approche recommandée, celle pour laquelle External ID a été conçue. Si vous invitez simplement des partenaires à accéder à des ressources internes, l'option tenant Workforce convient très bien.

L'essentiel est de comprendre la différence avant de commencer à bâtir, car migrer de l'un à l'autre plus tard n'est pas chose aisée. Sécurité, MFA et accès conditionnel Parlons maintenant de la sécurité. Si vous autorisez des clients à accéder à votre application, vous devez vous assurer que les personnes non autorisées ne puissent pas entrer. External ID inclut les mêmes fonctionnalités de sécurité de niveau entreprise qu'Entra ID propose pour les employés. Cela inclut l'authentification multifacteur, l'accès conditionnel et les politiques basées sur les risques. Pour le MFA, vous avez actuellement deux options. Le code d'accès unique par email est gratuit. Le système envoie un code à l'adresse email de l'utilisateur, il le saisit et c'est terminé. Le code d'accès unique par SMS fonctionne de la même manière, mais via le téléphone, avec des coulis à l'opérateur. Un point à noter, il n'y a pas encore de prise en charge de Microsoft Authenticator.

C'est une limitation actuelle, sur laquelle Microsoft travaille probablement, mais pour l'instant, c'est email ou SMS. L'accès conditionnel est là où les choses deviennent intéressantes. Vous pouvez définir des règles exigeant, par exemple le MFA lorsque le niveau de risque de connexion est moyen ou élevé, ou bloquer l'accès depuis des pays où vous ne travaillez pas. Le système évalue chaque tentative de connexion en temps réel. Si quelqu'un tente de se connecter depuis un emplacement ou un appareil suspect, il peut automatiquement renforcer les exigences de sécurité sans que vous ayez à développer cette logique vous-même. Mais il existe une fonctionnalité qui se démarque vraiment, l'authentification renforcée, c'est un peu potentiel. Voici comment cela fonctionne. Imaginez qu'un utilisateur se connecte à votre application avec juste un mot de passe pour parcourir votre catalogue de produits.

C'est suffisant pour des activités à faible risque. Mais lorsqu'il essaie de consulter son historique de paiement ou de télécharger une facture, vous souhaitez une vérification supplémentaire. Avec l'authentification renforcée, vous pouvez exiger les MFA uniquement pour certaines sections de votre application. L'utilisateur n'est pas sollicité tant qu'il n'essaie pas d'accéder à une ressource sensible. Tout est géré en arrière-plan par External ID à l'aide de ce qu'on appelle le contexte d'authentification. Vous définissez les parties de votre application, nécessitant une sécurité accrue et le système s'occupe du reste. L'utilisateur bénéficie d'une navigation fluide tout en protégeant les données sensibles. Image de marque et expérience utilisateur Le contrôle de l'image de marque est l'une des principales raisons pour lesquelles les entreprises choisissent External ID plutôt que de créer leur propre système.

Vous avez un contrôle total sur l'apparence de vos pages d'inscription et de connexion. Importez votre logo, définissez les couleurs d'arrière-plan, ajoutez un favicon et personnalisez l'entête et le pied de page avec vos liens Lego. Pour plus de contrôle, vous pouvez charger un fichier CSS personnalisé afin de modifier les polices, les couleurs des boutons et la mise en page. C'est votre marque, vos couleurs, c'est vous qui décidez de tout. C'est là que les choses se compliquent un peu. Image de marque est globale par locataire et non par application. Ainsi, si vous avez plusieurs applications, comme un portail client et une application mobile, elles partagent toutes les mêmes pages personnalisées. Vous ne pouvez pas donner à chaque application son propre. L'ancien Azure ID B2C permettait une personnalisation par application, mais External ID ne le permet pas encore. Autre limitation, les messages d'erreur sur les pages de connexion ne sont pas personnalisables.

Si quelqu'un saisit une adresse email inexistante, il verra un message du type PECS, ils ne vont pas trouver de compte avec cette adresse email, et vous ne pouvez pas modifier ce texte. Pour certaines organisations, cela convient, mais pour d'autres, notamment dans les secteurs réglementés ou avec une charte graphique stricte, c'est un vrai problème. Les applications mobiles bénéficient d'une Europe. External ID dispose d'une API d'authentification native pour iOS et Android. Au lieu de rediriger les utilisateurs vers une page de connexion web, vous pouvez créer des écrans de connexion entièrement personnalisés dans votre application. Pas de redirection de navigateur ni de vue web plus ergonomique. L'utilisateur reste dans votre application tout du long et vous contrôlez chaque pixel. L'expérience est beaucoup plus fluide et c'est une fonctionnalité qu'Azure AD B2C n'a jamais eue. Migration depuis Azure AD B2C Si vous utilisez déjà Azure AD B2C, vous vous demandez probablement ce que cela signifie pour vous.

Voici la situation. Microsoft continuera de prendre en charge B2C au moins jusqu'en 2030. Vos locataires actuels ne cesseront pas de fonctionner demain, mais aucune nouvelle fonctionnalité n'y sera ajoutée. Toutes les innovations, comme les passes key, l'authentification native et la protection de la fraude, sont exclusives à External ID. Vous utilisez une plateforme qui est par essence figée. Microsoft a publié des outils et des guides de migration officiels. Il existe deux voies selon votre envergure. Pour les tenants comptant moins de 5 millions d'objets d'annuaire, utilisateurs, groupes et attributs personnalisés, la migration standard est assez directe. Cela fonctionne comme un transfert entre tenants. Vous créez un nouveau tenant External ID, migrez vos utilisateurs et leurs identifiants, puis basculez vos applications. Microsoft fournit des outils d'exportation et d'importation en masse, et vous pouvez utiliser la migration de mots de passe key, juste attendez pour limiter les interruptions.

Pour les tenants plus importants de plus de 5 millions d'objets, il existe le mode de compatibilité à grande échelle, ou HSC. Dans ce mode, Azure AD B2C et External ID fonctionnent côte à côte dans le même tenant. Vos endpoints B2C existants restent actifs pendant que vous déplacez progressivement vos applications. Il est conçu pour les organisations qui ne peuvent migrer des millions d'utilisateurs du jour au lendemain, mais il impose des compromis. Pas de fournisseur d'identité sociale, pas de passe keys, un accès conditionnel limité, et certaines fonctionnalités ne sont tout simplement pas disponibles. Considérez cela comme une stratégie de transition, pas comme une solution permanente. Maintenant un changement majeur. Les stratégies personnalisées ont disparu. Si vous avez construit des flux d'authentification complexes avec le framework XML d'Azure AD B2C, ils ne fonctionneront pas dans External ID.

Vous devrez reconstruire cette logique en utilisant des flux d'utilisateurs et des extensions d'authentification personnalisées. Il n'existe aucun outil magique pour convertir votre XML dans le nouveau format. Vous devez simplement faire le travail. Alors voici ce qu'il en ressort. Si vous repartez de zéro aujourd'hui, utilisez External ID. Il n'y a aucune raison de s'intéresser à B2C. Si vous avez déjà un tenant B2C, commencez à planifier votre migration dès maintenant. Vous avez jusqu'en 2030, mais attendre la dernière minute signifie que vous devrez précipiter une migration complexe tout en maintenant vos applications actives, actives. Bon c'est petit. Foisissez une application, migrez-la, testez-la, apprenez du processus, puis faites le reste. Expérience développeur et automatisation. Microsoft est vraiment concentré sur la simplicité d'External ID pour les développeurs. Un immense changement par rapport aux anciennes stratégies B2C.

Oui. Vous vous souvenez de ces fichiers XML qui s'étalaient sur des centaines de lignes et plantaient à la moindre erreur de parenthèse ? C'est terminé. Il existe une extension Visual Studio Code appelée Microsoft Entra External ID. Après authentification, vous pouvez parcourir votre tenant, voir les flux, les télécharger en JSON et prévisualiser votre image de marque, sans quitter l'éditeur. Voyez à quoi ressemble votre page de connexion avant même de la publier. Ensuite, il y a l'API Microsoft Graph. Presque chaque ressource External ID, flux, enregistrement d'application, image de marque peut être géré par programme. Cela signifie que vous automatisez la configuration de votre tenant dans vos pipelines CI CCD via PowerShell ou des appels REST. Créer un nouveau tenant, configurer les flux d'utilisateurs, enregistrer votre application, personnaliser la marque le tout via un script. Si vous gérez plusieurs environnements, cela permet de gagner un temps précieux.

Les extensions d'authentification personnalisées sont là au résil de la vérité plus. Au lieu de XML complexe, vous étendez les flux d'authentification avec de simples appels HTTP vers Azure Functions. Il existe quatre événements sur lesquels vous pouvez vous gréver. Les missions de jetons permettent d'ajouter des revendications personnalisées aux jetons, comme des rôles ou des niveaux de fidélité. La collecte d'attributs permet de valider ou de pré-remplir les données d'inscription en appelant votre propre back-end. Et l'envoi d'OTP par email vous permet de personnaliser les emails de vérification. C'est la même flexibilité que B2C, mais dans un modèle accessible à tout développeur. Il y a des limites à connaître. Pas encore de notification Microsoft Graph, vous ne pouvez donc pas déclencher automatiquement un flux lors d'une inscription. Certaines configurations restent manuelles dans le centre et il n'y a pas de page de profil intégrée.

Si vous voulez que les utilisateurs modifient leurs informations, créez la page dans votre application et appelez l'API Graph vous-même. Mais la direction est claire. Microsoft veut que l'identifiant externe soit entièrement automatisable. Cela facilite la gestion à grande échelle. Vous savez désormais que Microsoft Entra External ID et le remplaçant moderne d'Azure ADBIT aussi unifié sous la marque Entra. Les trois cas d'usage, identité client, collaboration partenaire et machine à machine, couvrent presque tous vos besoins externes. La décision clé est d'utiliser votre tenant workforce ou d'en créer un externe distinct. Pour les applications clients, une séparation est presque toujours préférable. L'identité est la porte d'entrée de votre application. La rendre fiable, sécurisée, personnalisée et simple impacte directement la confiance des utilisateurs et la croissance et la croissance.

Votre devoir, allez sur Entra.Microsoft.com, créez un tenant externe et essayez le guide de démarrage. Il vous guidera dans la configuration d'une application exemple en quelques minutes. Abonnez-vous pour plus d'analyse simple sur la plateforme d'identité de Microsoft.