Configurer xID avec Azure Active Directory B2C pour l’authentification sans mot de passe
Article
Dans ce tutoriel, découvrez comment intégrer l’authentification Azure Active Directory B2C (Azure AD B2C) à la solution d’ID numérique xID. L’application xID fournit aux utilisateurs une authentification multifacteur sécurisée et sans mot de passe. La carte My Number, la carte d'identité numérique émise par le gouvernement japonais, vérifie les identités des utilisateurs authentifiés par xID. Les organisations peuvent ainsi faire vérifier les informations d’identification personnelles (contenu client) de leurs utilisateurs via l’API xID. En outre, l’application xID génère une clé privée dans une zone sécurisée dans les appareils mobiles des utilisateurs, ce qui en fait des appareils de signature numérique.
Vos informations clientes xID fournies par xID inc.
Accédez à la page Contactez-nous de xid.inc pour obtenir des informations sur le client xID :
ID client
Clé secrète client
URL de redirection
Étendues
Accédez à x-id.me pour installer l’application xID sur un appareil mobile :
Ma carte My Number
Si vous utilisez la version UAT de l’API, obtenez la version UAT de l’application xID. Consultez Contactez-nous
Description du scénario
Le diagramme suivant présente l’architecture.
Dans la page de connexion Azure AD B2C, l’utilisateur se connecte ou s’inscrit.
Azure AD B2C redirige l’utilisateur vers le point de terminaison d’API d’autorisation xID en utilisant une requête OpenID Connect (OIDC). Un point de terminaison OIDC contient des informations de point de terminaison. Le fournisseur d’identité xID redirige l’utilisateur vers la page de connexion d’autorisation xID. L’utilisateur entre l’adresse e-mail.
Le fournisseur d’identité xID envoie la notification Push à l’appareil mobile de l’utilisateur.
L’utilisateur ouvre l’application xID, vérifie la demande, entre un code confidentiel ou utilise la biométrie. L’application xID active la clé privée et crée une signature électronique.
L’application xID envoie la signature au fournisseur d’identité xID pour vérification.
Un écran de consentement s’affiche pour fournir des informations personnelles au service.
Le fournisseur d’identité xID retourne le code d’autorisation OAuth à Azure AD B2C.
En utilisant le code d’autorisation, Azure AD B2C envoie une demande de jeton.
Le fournisseur d’identité xID vérifie la demande de jeton. S’il est valide, le jeton d’accès OAuth est retourné et le jeton d’ID avec l’identificateur d’utilisateur et l’adresse e-mail.
Si le contenu du client utilisateur est nécessaire, Azure AD B2C appelle l’API de données utilisateur xID.
L’API user data de xID retourne le contenu du client chiffré. Les utilisateurs décryptent à l'aide d'une clé privée, créée lors de la demande d'informations sur le client xID.
L’accès à l’application client est accordé ou refusé à l’utilisateur.
Installer xID
Pour demander des documents d’API, remplissez le formulaire de demande. Accédez à Nous contacter.
Dans le message, indiquez que vous utilisez Azure AD B2C.
Un représentant commercial xID vous contacte.
Suivez les instructions du document d’API xID.
Demandez un client d’API xID.
L’équipe technique de xID vous envoie les informations du client sous 3-4 jours ouvrables.
Fournissez un URI de redirection dans votre site à l’aide du modèle suivant. Les utilisateurs y reviennent après l’authentification.
Stockez la clé secrète client xID dans votre locataire Azure AD B2C. Pour les instructions suivantes, utilisez le répertoire avec le locataire Azure AD B2C.
Pour que les utilisateurs se connectent avec xID, définissez xID comme fournisseur de revendications avec lequel Azure AD B2C peut communiquer via un point de terminaison. Le point de terminaison fournit des revendications utilisées par Azure AD B2C pour vérifier l’authentification des utilisateurs sur leur appareil avec un ID numérique.
Ajouter xID en tant que fournisseur de revendications
Récupérez les packs de démarrage de stratégie personnalisés à partir de GitHub, puis mettez à jour les fichiers XML dans le pack de démarrage SocialAccounts avec votre nom de locataire Azure AD B2C.
Dans les fichiers du répertoire SocialAccounts, remplacez la chaîne yourtenant par le nom de votre locataire Azure AD B2C. Par exemple, yourtenant.onmicrosoft.com devient contoso.onmicrosoft.com.
Open the SocialAccounts/TrustFrameworkExtensions.xml.
Recherchez l’élément ClaimsProviders. S’il n’y en a pas, ajoutez-le sous l’élément racine.
Ajoutez un nouveau ClaimsProvider semblable au fournisseur suivant :
Définissez client_id avec votre ID d’application xID.
Sélectionnez Enregistrer.
Ajouter un parcours utilisateur
Ajoutez un fournisseur d’identité aux pages de connexion.
Si vous avez un parcours utilisateur personnalisé, accédez à Ajouter le fournisseur d’identité à un parcours utilisateur. Sinon, créez un doublon du parcours utilisateur d’un modèle :
Dans le pack de démarrage, ouvrez TrustFrameworkBase.xml.
Repérez et copiez le contenu de l’élément UserJourneys qui comprend ID=SignUpOrSignIn.
Ouvrez le fichier TrustFrameworkExtensions.xml, puis recherchez l’élément UserJourneys. S’il n’y en a pas, ajoutez-en un.
Collez le contenu de l’élément UserJourney en tant qu’enfant de l’élément UserJourneys.
Renommez l’ID du parcours utilisateur. Par exemple : ID=CustomSignUpSignIn
Ajoutez le fournisseur d’identité à un parcours utilisateur
Ajoutez le nouveau fournisseur d’identité au parcours utilisateur.
Dans le parcours utilisateur, repérez l’élément d’étape d’orchestration avec Type=CombinedSignInAndSignUp ou Type=ClaimsProviderSelection. Il s’agit généralement de la première étape d’orchestration. L’élément ClaimsProviderSelections a une liste de fournisseurs d’identité pour la connexion. L’ordre des éléments contrôle l’ordre des boutons de connexion.
Ajoutez un élément XML ClaimsProviderSelection.
Définissez la valeur TargetClaimsExchangeId sur un nom convivial.
Ajoutez un élément ClaimsExchange.
Définissez l’ID sur la valeur de l’ID cible d’échange des revendications. Cette modification lie le bouton xID à l’action X-IDExchange.
Mettez à jour la valeur TechnicalProfileReferenceId sur l’ID de profil technique que vous avez créé (X-ID-OIDC).
Ajoutez une étape d’orchestration pour appeler un point de terminaison UserInfo xID afin qu’il renvoie des revendications sur l’utilisateur authentifié X-ID-Userdata.
Le code XML suivant montre les étapes d’orchestration d’un parcours utilisateur avec le fournisseur d’identité xID.
<UserJourney Id="CombinedSignInAndSignUp">
<OrchestrationSteps>
<OrchestrationStep Order="1" Type="CombinedSignInAndSignUp" ContentDefinitionReferenceId="api.signuporsignin">
<ClaimsProviderSelections>
<ClaimsProviderSelection TargetClaimsExchangeId="X-IDExchange" />
</ClaimsProviderSelections>
</OrchestrationStep>
<OrchestrationStep Order="2" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="X-IDExchange" TechnicalProfileReferenceId="X-ID-OIDC" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="3" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="X-ID-Userdata" TechnicalProfileReferenceId="X-ID-Userdata" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- For social IDP authentication, attempt to find the user account in the directory. -->
<OrchestrationStep Order="4" Type="ClaimsExchange">
<ClaimsExchanges>
<ClaimsExchange Id="AADUserReadUsingAlternativeSecurityId" TechnicalProfileReferenceId="AAD-UserReadUsingAlternativeSecurityId-NoError" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- Show self-asserted page only if the directory does not have the user account already (i.e. we do not have an objectId). -->
<OrchestrationStep Order="5" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="SelfAsserted-Social" TechnicalProfileReferenceId="SelfAsserted-Social" />
</ClaimsExchanges>
</OrchestrationStep>
<!-- The previous step (SelfAsserted-Social) could have been skipped if there were no attributes to collect
from the user. So, in that case, create the user in the directory if one does not already exist
(verified using objectId which would be set from the last step if account was created in the directory. -->
<OrchestrationStep Order="6" Type="ClaimsExchange">
<Preconditions>
<Precondition Type="ClaimsExist" ExecuteActionsIf="true">
<Value>objectId</Value>
<Action>SkipThisOrchestrationStep</Action>
</Precondition>
</Preconditions>
<ClaimsExchanges>
<ClaimsExchange Id="AADUserWrite" TechnicalProfileReferenceId="AAD-UserWriteUsingAlternativeSecurityId" />
</ClaimsExchanges>
</OrchestrationStep>
<OrchestrationStep Order="7" Type="SendClaims" CpimIssuerTechnicalProfileReferenceId="JwtIssuer" />
</OrchestrationSteps>
<ClientDefinition ReferenceId="DefaultWeb" />
</UserJourney>
Il existe des revendications d’identité que xID prend en charge et qui sont référencées dans le cadre de la stratégie. Le schéma de revendications est l’endroit où vous déclarez ses revendications. L’élément ClaimsSchema a une liste d’éléments ClaimType. L’élément ClaimType contient l’attribut ID, qui est le nom de la revendication.
Open the TrustFrameworksExtension.xml.
Recherchez l’élément BuildingBlocks.
Ajoutez l’élément ClaimType suivant dans l’élément ClaimsSchema de la stratégie TrustFrameworksExtension.xml
Découvrez comment l’ID externe Microsoft Entra peut fournir des expériences de connexion sécurisées et transparentes pour vos consommateurs et clients professionnels. Explorez la création du locataire, l’inscription d’applications, la personnalisation des flux et la sécurité des comptes.
Expliquez les fonctionnalités de Microsoft Entra ID pour moderniser des solutions d’identité, implémenter des solutions hybrides et une gouvernance des identités.