Remarque
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de vous connecter ou de modifier des répertoires.
L’accès à cette page nécessite une autorisation. Vous pouvez essayer de modifier des répertoires.
Important
À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.
De nombreuses applications modernes ont une interface d'application à page unique (SPA) écrite principalement en JavaScript. Souvent, l’application est écrite à l’aide d’une infrastructure telle que React, Angular ou Vue.js. Les applications monopages et autres applications JavaScript qui s’exécutent principalement dans un navigateur présentent certaines problématiques supplémentaires pour l’authentification :
Les caractéristiques de sécurité de ces applications sont différentes des applications web traditionnelles basées sur un serveur.
De nombreux serveurs d’autorisation et fournisseurs d’identité ne prennent pas en charge les demandes de partage de ressources entre origines (CORS).
Les redirections en plein écran du navigateur qui éloignent l'utilisateur de l'application peuvent être envahissantes pour l'expérience utilisateur.
Avertissement
Microsoft vous recommande de ne pas utiliser le flux d’octroi implicite. La façon recommandée de prendre en charge les spAs est le flux de code d’autorisation OAuth 2.0 (avec PKCE). Certaines configurations de ce flux nécessitent un degré de confiance très élevé dans l’application et comporte des risques qui ne sont pas présents dans d’autres flux. Utilisez ce flux uniquement lorsqu’aucun autre flux plus sécurisé n’est viable. Pour plus d’informations, consultez les problèmes de sécurité liés au flux d’octroi implicite.
Certaines infrastructures, comme MSAL.js 1.x, prennent uniquement en charge le flux d’octroi implicite. Dans ces cas, Azure Active Directory B2C (Azure AD B2C) prend en charge le flux d’octroi implicite d’autorisation OAuth 2.0. Le flux est décrit dans la section 4.2 de la spécification OAuth 2.0. En flux implicite, l’application reçoit des jetons directement à partir du point de terminaison d’autorisation Azure AD B2C, sans échange de serveur à serveur. Toute la logique d’authentification et la gestion des sessions sont entièrement effectuées dans le client JavaScript avec une redirection de page ou une zone contextuelle.
Azure AD B2C étend le flux implicite OAuth 2.0 standard à plus que l’authentification et l’autorisation simples. Azure AD B2C introduit le paramètre de stratégie. Avec le paramètre de stratégie, vous pouvez utiliser OAuth 2.0 pour ajouter des stratégies à votre application, telles que l’inscription, la connexion et les flux utilisateur de gestion des profils. Dans l’exemple de requêtes HTTP de cet article, nous utilisons {tenant}.onmicrosoft.com pour l’illustration. Remplacez {tenant}par le nom de votre locataire si vous en avez un. En outre, vous devez avoir créé un flux utilisateur.
Nous utilisons la figure suivante pour illustrer le flux de connexion implicite. Chaque étape est décrite en détail plus loin dans l’article.
Envoyer des demandes d’authentification
Lorsque votre application web doit authentifier l’utilisateur et exécuter un flux d’utilisateur, elle dirige l’utilisateur vers le point de terminaison d’Azure /authorize AD B2C. L’utilisateur prend des mesures en fonction du flux utilisateur.
Dans cette demande, le client indique les autorisations qu’il doit acquérir auprès de l’utilisateur dans le scope paramètre et le flux utilisateur à exécuter. Pour avoir une idée du fonctionnement de la requête, essayez de coller la requête dans un navigateur et de l’exécuter. Remplacez :
{tenant}par le nom de votre locataire Azure AD B2C.00001111-aaaa-2222-bbbb-3333cccc4444par l’ID de l’application que vous avez inscrite dans votre locataire.{policy}par le nom d’une stratégie que vous avez créée dans votre locataire, par exempleb2c_1_sign_in.
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=id_token+token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&response_mode=fragment
&scope=openid%20offline_access
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
Les paramètres de la requête HTTP GET sont expliqués dans le tableau ci-dessous.
| Paramètre | Obligatoire | Descriptif |
|---|---|---|
| {locataire} | Oui | Nom de votre locataire Azure AD B2C |
| {politique} | Oui | Nom du flux d’utilisateur que vous souhaitez exécuter. Spécifiez le nom d’un flux d’utilisateur que vous avez créé dans votre locataire Azure AD B2C. Par exemple : b2c_1_sign_in, b2c_1_sign_up, ou b2c_1_edit_profile. |
| client_id | Oui | ID d’application attribué au portail Azure à votre application. |
| type_de_réponse | Oui | Doit inclure id_token pour la connexion OpenID Connect. Il peut également inclure le type tokende réponse . Si vous utilisez token, votre application peut recevoir immédiatement un jeton d’accès à partir du point de terminaison d’autorisation, sans effectuer une deuxième demande au point de terminaison d’autorisation. Si vous utilisez le token type de réponse, le scope paramètre doit contenir une étendue qui indique la ressource pour laquelle émettre le jeton. |
| redirect_uri | Non | L’URI de redirection de votre application, vers lequel votre application peut envoyer et recevoir des réponses d’authentification. Elle doit correspondre exactement à l’une des URI de redirection que vous avez ajoutées à une application inscrite dans le portail, sauf qu’elle doit être encodée par URL. |
| mode_de_réponse | Non | Spécifie la méthode à utiliser pour renvoyer le jeton résultant à votre application. Pour les flux implicites, utilisez fragment. |
| portée | Oui | Une liste d’étendues séparées par des espaces. Une valeur d’étendue unique indique à Microsoft Entra ID les deux autorisations demandées. L’étendue openid indique une autorisation pour connecter l’utilisateur et obtenir des données relatives à l’utilisateur sous la forme de jetons d’ID. L’étendue offline_access est facultative pour les applications web. Elle indique que votre application a besoin d’un jeton d’actualisation pour l’accès à long terme aux ressources. |
| état | Non | Une valeur incluse dans la requête qui est également renvoyée dans la réponse du jeton. Il peut s’agir d’une chaîne de tout contenu que vous souhaitez utiliser. En règle générale, une valeur unique générée de manière aléatoire est utilisée pour empêcher les attaques par falsification de requête intersite. L’état est également utilisé pour encoder des informations sur l’état de l’utilisateur dans l’application avant la demande d’authentification, par exemple, la page sur laquelle l’utilisateur était activé ou le flux utilisateur en cours d’exécution. |
| nonce | Oui | Valeur incluse dans la requête (générée par l’application) incluse dans le jeton d’ID résultant en tant que revendication. L'application peut ensuite vérifier cette valeur afin de contrer les attaques de rejouement de jetons. En règle générale, la valeur est une chaîne aléatoire unique qui peut être utilisée pour identifier l’origine de la requête. |
| prompt | Non | Type d’interaction utilisateur requise. Actuellement, la seule valeur valide est login. Ce paramètre force l’utilisateur à entrer ses informations d’identification sur cette demande. L’authentification unique ne prend pas effet. |
Il s’agit de la partie interactive du flux. L’utilisateur est invité à terminer le flux de travail de la politique. L’utilisateur peut devoir entrer son nom d’utilisateur et son mot de passe, se connecter avec une identité sociale, s’inscrire à un compte local ou tout autre nombre d’étapes. Les actions utilisateur dépendent de la façon dont le flux utilisateur est défini.
Une fois que l’utilisateur a terminé le flux utilisateur, Azure AD B2C retourne une réponse à votre application via le redirect_uri. Elle utilise la méthode spécifiée dans le response_mode paramètre. La réponse est exactement la même pour chacun des scénarios d’action utilisateur, indépendamment du flux utilisateur qui a été exécuté.
Réponse réussie
Une réponse réussie qui utilise response_mode=fragment et response_type=id_token+token ressemble à ce qui suit, avec des sauts de ligne pour la lisibilité :
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&token_type=Bearer
&expires_in=3599
&scope="00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
&id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
| Paramètre | Descriptif |
|---|---|
| jeton d'accès | Jeton d’accès demandé par l’application auprès d’Azure AD B2C. |
| type_de_jeton | Valeur du type de jeton. Le seul type pris en charge par Azure AD B2C est Bearer. |
| expires_in | Durée pendant laquelle le jeton d’accès est valide (en secondes). |
| portée | Étendues de validité du jeton. Vous pouvez également utiliser des étendues pour mettre en cache des jetons pour une utilisation ultérieure. |
| Jeton d'identification (id_token) | Le jeton d'ID que l’application a demandé. Vous pouvez utiliser le jeton d'ID pour vérifier l’identité de l’utilisateur et démarrer une session avec lui. Pour plus d’informations sur les jetons d’ID et leur contenu, consultez la référence de jeton Azure AD B2C. |
| état | Si un paramètre state est inclus dans la demande, la même valeur doit apparaître dans la réponse. L’application doit vérifier que les state valeurs de la demande et de la réponse sont identiques. |
Réponse d’erreur
Les réponses d’erreur peuvent également être envoyées à l’URI de redirection afin que l’application puisse les gérer de manière appropriée :
GET https://aadb2cplayground.azurewebsites.net/#
error=access_denied
&error_description=the+user+canceled+the+authentication
&state=arbitrary_data_you_can_receive_in_the_response
| Paramètre | Descriptif |
|---|---|
| erreur | Code utilisé pour classifier les types d’erreurs qui se produisent. |
| description de l'erreur | Un message d’erreur spécifique qui peut vous aider à identifier la cause principale d’une erreur d’authentification. |
| état | Si un paramètre state est inclus dans la demande, la même valeur doit apparaître dans la réponse. L’application doit vérifier que les state valeurs de la demande et de la réponse sont identiques. |
Validation du jeton d’ID
La réception d’un jeton d’ID n’est pas suffisante pour authentifier l’utilisateur. Validez la signature du jeton d’ID et vérifiez les revendications dans le jeton conformément aux exigences de votre application. Azure AD B2C utilise des jetons web JSON (JWT) et un chiffrement à clé publique pour signer des jetons et vérifier qu’ils sont valides.
De nombreuses bibliothèques open source sont disponibles pour valider les JWT, en fonction du langage que vous préférez utiliser. Envisagez d’explorer les bibliothèques open source disponibles plutôt que d’implémenter votre propre logique de validation. Vous pouvez utiliser les informations contenues dans cet article pour vous aider à apprendre à utiliser correctement ces bibliothèques.
Azure AD B2C est doté d'un point de terminaison de métadonnées OpenID Connect. Une application peut utiliser le point de terminaison pour récupérer des informations sur Azure AD B2C au moment de l’exécution. Ces informations incluent les points de terminaison, le contenu des jetons et les clés de signature de jeton. Il existe un document de métadonnées JSON pour chaque flux utilisateur dans votre locataire Azure AD B2C. Par exemple, le document de métadonnées d’un flux utilisateur nommé b2c_1_sign_in dans un client fabrikamb2c.onmicrosoft.com est situé à :
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/v2.0/.well-known/openid-configuration
L’une des propriétés de ce document de configuration est la jwks_uri. La valeur du même flux d’utilisateur serait :
https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys
Pour déterminer le flux utilisateur utilisé pour signer un jeton d’ID (et où extraire les métadonnées), vous pouvez utiliser l’une des options suivantes :
Le nom du flux utilisateur est inclus dans la
acrrequête dansid_token. Pour plus d’informations sur l’analyse des revendications à partir d’un jeton d’ID, consultez la référence de jeton Azure AD B2C.Encoder le flux utilisateur dans la valeur du
stateparamètre lorsque vous émettez la requête. Ensuite, décodez lestateparamètre pour déterminer quel flux utilisateur a été utilisé.
Une fois que vous avez acquis le document de métadonnées à partir du point de terminaison de métadonnées OpenID Connect, vous pouvez utiliser les clés publiques RSA-256 (situées à ce point de terminaison) pour valider la signature du jeton d’ID. Il peut y avoir plusieurs clés répertoriées à ce point de terminaison à tout moment donné, chacune identifiée par un kid. L'en-tête de id_token contient également une mention de kid. Il indique quelles clés ont été utilisées pour signer le jeton d’ID. Pour plus d’informations, notamment sur la validation des jetons, consultez la référence de jeton Azure AD B2C.
Après avoir validé la signature du jeton d’ID, plusieurs revendications nécessitent une vérification. Par exemple:
Validez la revendication
nonceafin d’empêcher les attaques par relecture de jetons. Sa valeur doit être celle que vous avez spécifiée dans la demande de connexion.Validez la
audrevendication pour vous assurer que le jeton d’ID a été émis pour votre application. Sa valeur doit être l’ID d’application de votre application.Validez les déclarations
iatetexppour garantir que le jeton d'identification n'a pas expiré.
Plusieurs autres validations que vous devez effectuer sont décrites en détail dans la spécification OpenID Connect Core. Vous pouvez également valider des revendications supplémentaires, en fonction de votre scénario. Voici quelques validations courantes :
Assurez-vous que l’utilisateur ou l’organisation s’est inscrit à l’application.
S’assurer que l’utilisateur dispose d’autorisations et de privilèges appropriés.
S’assurer qu’un certain niveau d’authentification s’est produit, par exemple à l’aide de l’authentification multifacteur Microsoft Entra.
Pour plus d’informations sur les revendications dans un jeton d’ID, consultez la référence du jeton Azure AD B2C.
Une fois que vous avez validé le jeton d’ID, vous pouvez commencer une session avec l’utilisateur. Dans votre application, utilisez les revendications dans le jeton d’ID pour obtenir des informations sur l’utilisateur. Ces informations peuvent être utilisées pour l’affichage, les enregistrements, l’autorisation, et ainsi de suite.
Obtenir des jetons d’accès
Si la seule chose que vos applications web doivent faire est d’exécuter des flux utilisateur, vous pouvez ignorer les sections suivantes. Les informations contenues dans les sections suivantes s’appliquent uniquement aux applications web qui doivent effectuer des appels authentifiés à une API web protégée par Azure AD B2C lui-même.
Maintenant que vous avez signé l’utilisateur dans votre spa, vous pouvez obtenir des jetons d’accès pour appeler des API web sécurisées par l’ID Microsoft Entra. Même si vous avez déjà reçu un jeton à l’aide du token type de réponse, vous pouvez utiliser cette méthode pour acquérir des jetons pour des ressources supplémentaires sans rediriger l’utilisateur pour se reconnecter.
Dans un flux d’application web classique, vous devez effectuer une demande au /token point de terminaison. Toutefois, le point de terminaison ne prend pas en charge les requêtes CORS. Par conséquent, l’obtention d’un jeton d’actualisation par AJAX n’est pas une option. Au lieu de cela, vous pouvez utiliser le flux implicite dans un élément iframe HTML masqué pour obtenir de nouveaux jetons pour d’autres API web. Voici un exemple, avec des sauts de ligne pour la lisibilité :
https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=token
&redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
&response_mode=fragment
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345
&prompt=none
| Paramètre | Obligatoire ? | Descriptif |
|---|---|---|
| {locataire} | Obligatoire | Nom de votre locataire Azure AD B2C |
| {politique} | Obligatoire | Flux utilisateur à exécuter. Spécifiez le nom d’un flux d’utilisateur que vous avez créé dans votre locataire Azure AD B2C. Par exemple : b2c_1_sign_in, b2c_1_sign_up, ou b2c_1_edit_profile. |
| client_id | Obligatoire | ID d’application affecté à votre application dans le portail Azure. |
| type_de_réponse | Obligatoire | Doit inclure id_token pour la connexion à OpenID Connect. Il peut également inclure le type tokende réponse . Si vous utilisez token ici, votre application peut recevoir immédiatement un jeton d’accès à partir du point de terminaison d’autorisation, sans effectuer une deuxième demande au point de terminaison d’autorisation. Si vous utilisez le token type de réponse, le scope paramètre doit contenir une étendue qui indique la ressource pour laquelle émettre le jeton. |
| redirect_uri | Recommandé | L’URI de redirection de votre application, vers lequel votre application peut envoyer et recevoir des réponses d’authentification. Il doit correspondre exactement à un des URI de redirection inscrits dans le portail, sauf qu’il doit être codé dans une URL. |
| portée | Obligatoire | Une liste d’étendues séparées par des espaces. Pour obtenir des jetons, incluez toutes les étendues dont vous avez besoin pour la ressource concernée. |
| mode_de_réponse | Recommandé | Spécifie la méthode utilisée pour renvoyer le jeton résultant à votre application. Pour un flux implicite, utilisez fragment. Deux autres modes peuvent être spécifiés et queryform_post, mais ne fonctionnent pas dans le flux implicite. |
| état | Recommandé | Une valeur incluse dans la requête et retournée dans la réponse du jeton. Il peut s’agir d’une chaîne de tout contenu que vous souhaitez utiliser. En règle générale, une valeur unique générée de manière aléatoire est utilisée pour empêcher les attaques par falsification de requête intersite. L’état est également utilisé pour coder les informations sur l’état de l’utilisateur dans l’application avant la demande d’authentification. Par exemple, la page ou la vue sur laquelle l’utilisateur était. |
| nonce | Obligatoire | Une valeur incluse dans la requête, générée par l'application, qui est intégrée au jeton d'identité résultant en tant qu'assertion. L'application peut ensuite vérifier cette valeur afin de contrer les attaques de rejouement de jetons. En règle générale, la valeur est une chaîne aléatoire unique qui identifie l’origine de la requête. |
| prompt | Obligatoire | Pour actualiser et obtenir des jetons dans un iframe masqué, utilisez prompt=none pour vous assurer que l'iframe ne reste pas bloqué sur la page de connexion et retourne immédiatement. |
| indice de connexion | Obligatoire | Pour actualiser et obtenir des jetons dans un iframe masqué, incluez le nom d’utilisateur de l’utilisateur dans cet indicateur pour faire la distinction entre plusieurs sessions que l’utilisateur peut avoir à un moment donné. Vous pouvez extraire le nom d’utilisateur d’une connexion antérieure à l’aide de la preferred_username revendication (l’étendue profile est requise pour recevoir la preferred_username revendication). |
| domain_hint | Obligatoire | Peut être consumers ou organizations. Pour actualiser et obtenir des jetons dans un iframe masqué, incluez la domain_hint valeur dans la requête. Extrayez la revendication tid du jeton d’ID d’une connexion précédente pour déterminer la valeur à utiliser (l’étendue profile est nécessaire pour recevoir la revendication tid). Si la valeur de tid revendication est 9188040d-6c67-4c5b-b112-36a304b66dad, utilisez domain_hint=consumers. Sinon, utilisez domain_hint=organizations. |
En définissant le prompt=none paramètre, cette requête réussit ou échoue immédiatement et retourne à votre application. Une réponse réussie est envoyée à votre application via l’URI de redirection, à l’aide de la méthode spécifiée dans le response_mode paramètre.
Réponse réussie
Une réponse réussie à l’aide de response_mode=fragment ressemble à cet exemple :
GET https://aadb2cplayground.azurewebsites.net/#
access_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&state=arbitrary_data_you_sent_earlier
&token_type=Bearer
&expires_in=3599
&scope=https%3A%2F%2Fapi.contoso.com%2Ftasks.read
| Paramètre | Descriptif |
|---|---|
| jeton d'accès | Jeton demandé par l’application. |
| type_de_jeton | Le type de jeton sera toujours Porteur. |
| état | Si un paramètre state est inclus dans la demande, la même valeur doit apparaître dans la réponse. L’application doit vérifier que les state valeurs de la demande et de la réponse sont identiques. |
| expires_in | Durée de validité du jeton d’accès (en secondes). |
| portée | Étendues pour lesquelles le jeton d'accès est valide. |
Réponse d’erreur
Les réponses d’erreur peuvent également être envoyées à l’URI de redirection afin que l’application puisse les gérer de manière appropriée. Pour prompt=none, une erreur attendue ressemble à cet exemple :
GET https://aadb2cplayground.azurewebsites.net/#
error=user_authentication_required
&error_description=the+request+could+not+be+completed+silently
| Paramètre | Descriptif |
|---|---|
| erreur | Chaîne de code d’erreur qui peut être utilisée pour classifier les types d’erreurs qui se produisent. Vous pouvez également utiliser la chaîne pour réagir aux erreurs. |
| description de l'erreur | Un message d’erreur spécifique qui peut vous aider à identifier la cause principale d’une erreur d’authentification. |
Si vous recevez cette erreur dans la requête iFrame, l’utilisateur doit se connecter de nouveau de manière interactive, ceci pour récupérer un nouveau jeton.
Jetons d’actualisation
Les jetons d’ID et les jetons d’accès expirent tous deux après une courte période de temps. Votre application doit être prête à actualiser ces jetons régulièrement. Les flux implicites ne vous permettent pas d’obtenir un jeton d’actualisation en raison de raisons de sécurité. Pour actualiser l’un ou l’autre type de jeton, utilisez le flux implicite dans un élément iframe HTML masqué. Dans la demande d’autorisation, incluez le prompt=none paramètre. Pour recevoir une nouvelle valeur id_token, veillez à utiliser response_type=id_token et scope=openid, et à définir un paramètre nonce.
Envoi d’une demande de déconnexion
Lorsque vous souhaitez déconnecter l’utilisateur de l’application, redirigez l’utilisateur vers le point de terminaison de déconnexion d’Azure AD B2C. Vous pouvez ensuite effacer la session de l’utilisateur dans l’application. Si vous ne redirigez pas l’utilisateur, il peut être en mesure de se réauthentifier vers votre application sans entrer à nouveau ses informations d’identification, car il dispose d’une session de Sign-On unique valide avec Azure AD B2C.
Vous pouvez simplement rediriger l’utilisateur vers celui end_session_endpoint répertorié dans le même document de métadonnées OpenID Connect décrit dans Valider le jeton d’ID. Par exemple:
GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Faadb2cplayground.azurewebsites.net%2F
| Paramètre | Obligatoire | Descriptif |
|---|---|---|
| {locataire} | Oui | Nom de votre locataire Azure AD B2C. |
| {politique} | Oui | Flux utilisateur que vous souhaitez utiliser pour déconnecter l’utilisateur de votre application. Il doit s’agir du même flux utilisateur que celui utilisé par l’application pour connecter l’utilisateur. |
| URI_de_redirection_après_déconnexion | Non | URL vers laquelle l’utilisateur doit être redirigé après la déconnexion réussie. S’il n’est pas inclus, Azure AD B2C affiche à l’utilisateur un message générique. |
| état | Non | Si un paramètre state est inclus dans la demande, la même valeur doit apparaître dans la réponse. L’application doit vérifier que les state valeurs de la demande et de la réponse sont identiques. |
Remarque
Réorienter l'utilisateur vers end_session_endpoint permet de supprimer une partie de l'état Single Sign-On de l'utilisateur avec Azure AD B2C. Toutefois, il ne déconnecte pas l’utilisateur de la session du fournisseur d’identité sociale de l’utilisateur. Si l’utilisateur sélectionne le même fournisseur d’identité lors d’une connexion ultérieure, l’utilisateur est réauthentification, sans entrer ses informations d’identification. Si un utilisateur souhaite se déconnecter de votre application Azure AD B2C, cela ne signifie pas nécessairement qu’il souhaite se déconnecter complètement de son compte Facebook, par exemple. Toutefois, pour les comptes locaux, la session de l’utilisateur est terminée correctement.
Étapes suivantes
Consultez l’exemple de code : Se connecter avec Azure AD B2C dans un spa JavaScript.