Connexion web avec OpenID Connect - Azure AD B2C

2025-05-08

Important

À compter du 1er mai 2025, Azure AD B2C ne sera plus disponible pour les nouveaux clients. Pour plus d’informations, consultez notre FAQ.

OpenID Connect est un protocole d’authentification, basé sur OAuth 2.0, qui peut être utilisé pour connecter en toute sécurité les utilisateurs aux applications web. En utilisant l’implémentation d’Azure Active Directory B2C (Azure AD B2C) d’OpenID Connect, vous pouvez externaliser l’inscription, la connexion et d’autres expériences de gestion des identités dans vos applications web à Microsoft Entra ID. Ce guide vous montre comment procéder de manière indépendante de la langue. Il décrit comment envoyer et recevoir des messages HTTP sans utiliser nos bibliothèques open source.

Remarque

La plupart des bibliothèques d’authentification open source acquièrent et valident les JWT pour votre application. Nous vous recommandons d’explorer ces options plutôt que d’implémenter votre propre code. Pour plus d’informations, consultez Vue d’ensemble de la bibliothèque d’authentification Microsoft (MSAL) et de la bibliothèque d’authentification Web Microsoft Identity.

OpenID Connect étend le protocole d’autorisation OAuth 2.0 à utiliser comme protocole d’authentification . Ce protocole d’authentification vous permet d’effectuer une authentification unique. Il introduit le concept de jeton d’ID, qui permet au client de vérifier l’identité de l’utilisateur et d’obtenir des informations de profil de base sur l’utilisateur.

OpenID Connect permet également aux applications d’acquérir en toute sécurité des jetons d’accès. Vous pouvez utiliser des jetons d’accès pour accéder aux ressources sécurisées par le serveur d’autorisation . Nous vous recommandons OpenID Connect si vous créez une application web que vous hébergez sur un serveur et accessible via un navigateur. Pour plus d’informations sur les jetons, consultez la vue d’ensemble des jetons dans Azure Active Directory B2C

Azure AD B2C étend le protocole OpenID Connect standard pour effectuer plus que l’authentification et l’autorisation simples. Il introduit le paramètre de flux utilisateur, qui vous permet d’utiliser OpenID Connect pour ajouter des expériences utilisateur à votre application, telles que l’inscription, la connexion et la gestion des profils.

Envoyer des demandes d’authentification

Lorsque votre application web doit authentifier l’utilisateur et exécuter un flux d’utilisateur, elle peut diriger l’utilisateur vers le /authorize point de terminaison. 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 spécifie le flux utilisateur à exécuter. Pour avoir une idée du fonctionnement de la requête, collez la requête dans votre navigateur et exécutez-la. Remplacez :

{tenant} avec le nom de votre locataire.
00001111-aaaa-2222-bbbb-3333cccc4444 par l’identifiant de l’application que vous avez inscrite dans votre locataire.
{application-id-uri}/{scope-name} par exemple, avec l’identifiant d’application et l’étendue d’une application que vous avez inscrite dans votre locataire.
{policy} par exemple, avec le nom de la stratégie que vous avez dans votre locataire b2c_1_sign_in.

GET /{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/authorize?
Host: {tenant}.b2clogin.com

client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&response_type=code+id_token
&redirect_uri=https%3A%2F%2Fjwt.ms%2F
&response_mode=fragment
&scope=openid%20offline_access%20{application-id-uri}/{scope-name}
&state=arbitrary_data_you_can_receive_in_the_response
&nonce=12345

Paramètre	Obligatoire	Descriptif
{locataire}	Oui	Nom de votre locataire Azure AD B2C. Si vous utilisez un domaine personnalisé, remplacez-le `tenant.b2clogin.com` par votre domaine, par `fabrikam.com`exemple .
{politique}	Oui	Flux utilisateur ou stratégie que l’application exécute. Spécifiez le nom d’un flux d’utilisateur que vous créez 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.
nonce	Recommandé	Valeur incluse dans la requête (générée par l’application) qui est incluse dans le jeton d’ID résultant en tant que revendication. L’application peut ensuite vérifier cette valeur pour atténuer les attaques par relecture de jeton. La valeur est généralement une chaîne unique aléatoire qui peut être utilisée pour identifier l’origine de la requête.
type_de_réponse	Oui	Doit inclure un jeton d’ID pour OpenID Connect. Si votre application web a également besoin de jetons pour appeler une API web, vous pouvez utiliser `code+id_token`.
portée	Oui	Une liste d’étendues séparées par des espaces. 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 étendu aux ressources. `https://{tenant-name}/{app-id-uri}/{scope}` indique une autorisation pour les ressources protégées telles qu’une API web. Pour plus d’informations, consultez Demander un jeton d’accès.
prompt	Non	Type d’interaction utilisateur dont vous avez besoin. La seule valeur valide à ce stade est `login`, ce qui force l’utilisateur à entrer ses informations d’identification sur cette demande.
redirect_uri	Oui	Paramètre `redirect_uri` de votre application, où le serveur envoie des réponses d’authentification à votre application. Il doit correspondre exactement à l’un `redirect_uri` des paramètres que vous avez inscrits dans le portail Azure, sauf qu’il doit être encodé par URL.
mode_de_réponse	Non	Méthode utilisée pour renvoyer le code d’autorisation résultant à votre application. Il peut être soit `query`, ou `form_postfragment`. Nous vous recommandons d’utiliser le `form_post` mode réponse pour une sécurité optimale.
état	Non	Valeur que vous pouvez inclure dans la requête et que le serveur d’autorisation renvoie dans la réponse du jeton. Il peut s’agir d’une chaîne de n’importe quel contenu souhaité. Une valeur unique générée de manière aléatoire est généralement utilisée pour empêcher les falsifications 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 ils étaient activés. Si vous ne souhaitez pas inscrire plusieurs URL de redirection dans votre portail Azure, vous pouvez utiliser le `state` paramètre pour différencier les réponses dans votre application du service Azure AD B2C en raison de différentes demandes.
indice de connexion	Non	Peut être utilisé pour préremplir le champ nom de connexion de la page de connexion. Pour plus d’informations, consultez Préremplir le nom de connexion.
domain_hint	Non	Fournit un indicateur à Azure AD B2C sur le fournisseur d’identité sociale qui doit être utilisé pour la connexion. Si une valeur valide est incluse, l’utilisateur accède directement à la page de connexion du fournisseur d’identité. Pour plus d’informations, consultez Redirection de la connexion à un fournisseur de réseaux sociaux.
Paramètres personnalisés	Non	Paramètres personnalisés qui peuvent être utilisés avec des stratégies personnalisées. Par exemple, l'URI de contenu de page personnalisé dynamique ou les résolveurs de déclarations clé-valeur.

À ce stade, l’utilisateur est invité à terminer le flux de travail. L’utilisateur peut devoir entrer son nom d’utilisateur et son mot de passe, se connecter avec une identité sociale ou s’inscrire au répertoire. Il peut y avoir un autre nombre d’étapes en fonction de la façon dont le flux utilisateur est défini.

Une fois que l’utilisateur a terminé le flux utilisateur, une réponse est retournée à votre application au niveau du paramètre indiqué redirect_uri , à l’aide de la méthode que vous spécifiez dans le response_mode paramètre. La réponse est la même pour chacun des cas précédents, indépendamment du flux utilisateur.

Une réponse réussie à l’aide response_mode=fragment ressemble à ceci :

GET https://jwt.ms/#
id_token=eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&state=arbitrary_data_you_can_receive_in_the_response

Paramètre	Descriptif
Jeton d'identification (id_token)	Jeton d’ID demandé par l’application. Vous pouvez utiliser le jeton d'ID pour vérifier l’identité de l’utilisateur et démarrer une session avec lui.
code	Code d’autorisation demandé par l’application, si vous avez utilisé `response_type=code+id_token`. L’application peut utiliser le code d’autorisation pour demander un jeton d’accès pour une ressource cible. Les codes d’autorisation expirent généralement après environ 10 minutes.
é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.

Les réponses d’erreur peuvent également être envoyées au redirect_uri paramètre afin que l’application puisse les gérer de manière appropriée :

GET https://jwt.ms/#
error=access_denied
&error_description=AADB2C90091%3a+The+user+has+cancelled+entering+self-asserted+information.%0d%0aCorrelation+ID%3a+xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx%0d%0aTimestamp%3a+xxxx-xx-xx+xx%3a23%3a27Z%0d%0a
&state=arbitrary_data_you_can_receive_in_the_response

Paramètre	Descriptif
erreur	Code qui peut être utilisé pour classifier les types d’erreurs qui se produisent.
description de l'erreur	Message d’erreur spécifique qui peut aider à identifier la cause racine 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.

Remarque

La plupart des bibliothèques d’authentification open source valident les JWT pour votre application. Nous vous recommandons d’explorer ces options plutôt que d’implémenter votre propre logique de validation. Pour plus d’informations, consultez Vue d’ensemble de la bibliothèque d’authentification Microsoft (MSAL) et de la bibliothèque d’authentification Web Microsoft Identity.

Azure AD B2C a un point de terminaison de métadonnées OpenID Connect, ce qui permet à une application d’obtenir 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 d’utilisateur dans votre locataire B2C. Par exemple, le document de métadonnées du flux utilisateur b2c_1_sign_in dans fabrikamb2c.onmicrosoft.com se trouve à l’adresse suivante :

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 jwks_uri, dont la valeur pour le même flux utilisateur serait :

https://fabrikamb2c.b2clogin.com/fabrikamb2c.onmicrosoft.com/b2c_1_sign_in/discovery/v2.0/keys

Pour déterminer quel flux utilisateur a été utilisé pour signer un jeton d’ID, vous avez deux options. Tout d’abord, le nom du flux d’utilisateur est inclus dans la revendication acr du jeton d’ID, consultez Revendication représentant le flux d’utilisateur. Votre autre option consiste à encoder le flux utilisateur dans la valeur du state paramètre lorsque vous émettez la requête, puis à le décoder pour déterminer quel flux utilisateur a été utilisé. L’une ou l’autre méthode est valide.

Après avoir 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 pour valider la signature du jeton d’ID. Il peut y avoir plusieurs clés répertoriées sur ce point de terminaison, chacune identifiée par une kid revendication. L’en-tête du jeton d’ID contient également une kid revendication, qui indique laquelle de ces clés a été utilisée pour signer le jeton d’ID.

Pour vérifier les jetons d’Azure AD B2C, vous devez générer la clé publique à l’aide de l’exposant(e) et du module(n). Pour ce faire, vous devez apprendre à générer la clé publique dans un langage de programmation de votre choix. La documentation officielle sur la génération de clés publiques avec le protocole RSA est disponible ici : https://tools.ietf.org/html/rfc3447#section-3.1

Après avoir validé la signature du jeton d’ID, il existe différentes revendications que vous devez vérifier. Par exemple:

Validez la revendication nonce afin 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 aud revendication 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 revendications iat et exp pour vérifier que le jeton d’ID n’a pas expiré.

Il existe également plusieurs validations supplémentaires que vous devez effectuer. Les validations sont décrites en détail dans la spécification OpenID Connect Core. Vous pouvez également valider davantage de revendications, en fonction de votre scénario. Voici quelques validations courantes :

Vérifiez que l’utilisateur/l’organisation s’est inscrit à l’application.
Vérifiez que l’utilisateur dispose d’autorisations/privilèges appropriés.
Assurez-vous qu'un certain niveau de sécurité d'authentification a été atteint, comme l'authentification multifacteur Microsoft Entra.

Une fois le jeton d’ID validé, vous pouvez commencer une session avec l’utilisateur. Vous pouvez utiliser les revendications dans le jeton d’ID pour obtenir des informations sur l’utilisateur dans votre application. Les utilisations de ces informations incluent l’affichage, les enregistrements et l’autorisation.

Obtention d’un jeton

Si vous avez besoin que votre application web exécute uniquement des flux d’utilisateurs, vous pouvez ignorer les sections suivantes. Ces sections s’appliquent uniquement aux applications web qui doivent effectuer des appels authentifiés à une API web, qui est protégée par Azure AD B2C lui-même.

Vous pouvez utiliser le code d’autorisation que vous avez acquis (en utilisant response_type=code+id_token) pour obtenir un jeton pour accéder à la ressource souhaitée en envoyant une requête POST au point de terminaison /token. Dans Azure AD B2C, vous pouvez demander des jetons d’accès pour d’autres API comme d’habitude en spécifiant leur ou leurs étendues dans la requête.

Vous pouvez également demander un jeton d’accès pour l’API web principale de votre application. Dans ce cas, vous utilisez l’ID client de l’application comme étendue demandée, ce qui entraîne un jeton d’accès avec cet ID client comme « audience » :

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=authorization_code
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=00001111-aaaa-2222-bbbb-3333cccc4444 offline_access
&code=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Paramètre	Obligatoire	Descriptif
{locataire}	Oui	Nom de votre locataire Azure AD B2C
{politique}	Oui	Flux utilisateur utilisé pour acquérir le code d’autorisation. Vous ne pouvez pas utiliser un autre flux d’utilisateur dans cette requête. Ajoutez ce paramètre à la chaîne de requête, et non au corps POST.
client_id	Oui	ID d’application attribué au portail Azure à votre application.
secret du client	Oui, dans Web Apps	Secret d’application généré dans le portail Azure. Les secrets client sont utilisés dans ce flux pour les scénarios d’application web, où le client peut stocker en toute sécurité une clé secrète client. Pour les scénarios d’application native (client public), les secrets clients ne peuvent pas être stockés en toute sécurité, ce qui n’est pas utilisé sur ce flux. Si vous utilisez une clé secrète client, modifiez-la régulièrement.
code	Oui	Code d’autorisation que vous avez acquis au début du flux utilisateur.
type d'autorisation	Oui	Type d’octroi, qui doit être `authorization_code` pour le flux de code d’autorisation.
redirect_uri	Non	Paramètre `redirect_uri` de l’application où vous avez reçu le code d’autorisation.
portée	Non	Une liste d’étendues séparées par des espaces. L’étendue `openid` indique une autorisation de connexion à l’utilisateur et d’obtenir des données sur l’utilisateur sous la forme de paramètres id_token. Il peut être utilisé pour obtenir des jetons à l’API web principale de votre application, qui est représentée par le même ID d’application que le client. L’étendue `offline_access` indique que votre application a besoin d’un jeton d’actualisation pour l’accès étendu aux ressources.

Un jeton de réponse de réussite se présente ainsi :

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "expires_on": "1644254945",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
}

Paramètre	Descriptif
pas_avant	Heure à laquelle le jeton devient valide.
type_de_jeton	Valeur du type de jeton. `Bearer` est le seul type pris en charge.
jeton d'accès	Le JWT signé que vous avez demandé.
portée	Étendues valides pour le jeton.
expires_in	Durée pendant laquelle le jeton d’accès est valide (en secondes).
expire le	Heure à laquelle le jeton d’accès devient non valide.
jeton_de_actualisation	Un jeton d’actualisation OAuth 2.0. L’application peut utiliser ce jeton pour acquérir plus de jetons après l’expiration du jeton actuel. Les jetons d’actualisation peuvent être utilisés pour conserver l’accès aux ressources pendant des périodes prolongées. L’étendue `offline_access` doit avoir été utilisée dans les demandes d’autorisation et de jeton pour recevoir un jeton d’actualisation.

Les réponses d’erreur ressemblent à ceci :

{
    "error": "invalid_grant",
    "error_description": "AADB2C90080: The provided grant has expired. Please re-authenticate and try again. Current time: xxxxxxxxxx, Grant issued time: xxxxxxxxxx, Grant expiration time: xxxxxxxxxx\r\nCorrelation ID: xxxxxxxx-xxxx-xxxX-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-16 xx:10:52Z\r\n"
}

Paramètre	Descriptif
erreur	Code qui peut être utilisé pour classifier les types d’erreurs qui se produisent.
description de l'erreur	Message qui peut aider à identifier la cause racine d’une erreur d’authentification.

Utiliser le jeton

Une fois que vous avez acquis un jeton d’accès, vous pouvez utiliser le jeton dans les demandes à vos API web principales en l’incluant dans l’en-tête Authorization :

GET /tasks
Host: mytaskwebapi.com
Authorization: Bearer eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...

Actualiser le jeton

Les jetons d’accès et les jetons d’ID sont de courte durée. Une fois qu’ils expirent, vous devez les actualiser pour continuer à accéder aux ressources. Lorsque vous actualisez le jeton d’accès, Azure AD B2C retourne un nouveau jeton. Le jeton d’accès actualisé a des valeurs de revendication mises à jour : nbf (pas avant), iat (émis à) et exp (expiration). Toutes les autres valeurs de revendication sont similaires à celles du jeton d’accès précédent.

Actualisez un jeton en envoyant une nouvelle demande POST au point de terminaison /token. Cette fois, fournissez le refresh_token paramètre au lieu du code paramètre :

POST https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/token HTTP/1.1
Host: {tenant}.b2clogin.com
Content-Type: application/x-www-form-urlencoded

grant_type=refresh_token
&client_id=00001111-aaaa-2222-bbbb-3333cccc4444
&scope=openid offline_access
&refresh_token=AwABAAAAvPM1KaPlrEqdFSBzjqfTGBCmLdgfSTLEMPGYuNHSUYBrq...
&redirect_uri=urn:ietf:wg:oauth:2.0:oob

Paramètre	Obligatoire	Descriptif
{locataire}	Oui	Nom de votre locataire Azure AD B2C
{politique}	Oui	Flux utilisateur utilisé pour acquérir le jeton d’actualisation d’origine. Vous ne pouvez pas utiliser un autre flux d’utilisateur dans cette requête. Ajoutez ce paramètre à la chaîne de requête, et non au corps POST.
client_id	Oui	ID d’application attribué au portail Azure à votre application.
secret du client	Oui, dans Web Apps	Secret d’application généré dans le portail Azure. Les secrets client sont utilisés dans ce flux pour les scénarios d’application web, où le client peut stocker en toute sécurité une clé secrète client. Pour les scénarios d’application native (client public), les secrets client ne peuvent pas être stockés en toute sécurité, ce qui n’est donc pas utilisé sur cet appel. Si vous utilisez une clé secrète client, modifiez-la régulièrement.
type d'autorisation	Oui	Type d’octroi, qui doit être `refresh_token` pour cette partie du flux de code d’autorisation.
jeton_de_actualisation	Oui	Jeton d’actualisation d’origine qui a été acquis dans la seconde partie du flux. L’étendue `offline_access` doit être utilisée dans les demandes d’autorisation et de jeton pour recevoir un jeton d’actualisation.
redirect_uri	Non	Paramètre `redirect_uri` de l’application où vous avez reçu le code d’autorisation.
portée	Non	Une liste d’étendues séparées par des espaces. 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. Il peut être utilisé pour envoyer des jetons à l’API web principale de votre application, qui est représentée par le même ID d’application que le client. L’étendue `offline_access` indique que votre application a besoin d’un jeton d’actualisation pour l’accès étendu aux ressources.

Un jeton de réponse de réussite se présente ainsi :

{
    "not_before": "1442340812",
    "token_type": "Bearer",
    "access_token": "eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik5HVEZ2ZEstZnl0aEV1Q...",
    "scope": "00001111-aaaa-2222-bbbb-3333cccc4444 offline_access",
    "expires_in": "3600",
    "refresh_token": "AAQfQmvuDy8WtUv-sd0TBwWVQs1rC-Lfxa_NDkLqpg50Cxp5Dxj0VPF1mx2Z...",
    "refresh_token_expires_in": "1209600"
}

Paramètre	Descriptif
pas_avant	Heure à laquelle le jeton devient valide.
type_de_jeton	Valeur du type de jeton. `Bearer` est le seul type pris en charge.
jeton d'accès	Le JWT signé qui a été demandé.
portée	Étendues valides pour le jeton.
expires_in	Durée pendant laquelle le jeton d’accès est valide (en secondes).
jeton_de_actualisation	Un jeton d’actualisation OAuth 2.0. L’application peut utiliser ce jeton pour acquérir des jetons supplémentaires après l’expiration du jeton actuel. Les jetons d’actualisation peuvent être utilisés pour conserver l’accès aux ressources pendant des périodes prolongées.
refresh_token_expires_in	Durée pendant laquelle le jeton d’actualisation est valide (en secondes).

Les réponses d’erreur ressemblent à ceci :

{
    "error": "invalid_grant",
    "error_description": "AADB2C90129: The provided grant has been revoked. Please reauthenticate and try again.\r\nCorrelation ID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx\r\nTimestamp: xxxx-xx-xx xx:xx:xxZ\r\n",
}

Paramètre	Descriptif
erreur	Code qui peut être utilisé pour classifier les types d’erreurs qui se produisent.
description de l'erreur	Message qui peut aider à identifier la cause racine d’une erreur d’authentification.

Envoi d’une demande de déconnexion

Lorsque vous souhaitez déconnecter l’utilisateur de l’application, il n’est pas suffisant d’effacer les cookies de l’application ou de mettre fin à la session avec l’utilisateur. Redirigez l’utilisateur vers Azure AD B2C pour vous déconnecter. Si vous ne parvenez pas à le faire, l’utilisateur peut être en mesure de se réauthentifier à votre application sans entrer à nouveau ses informations d’identification. Pour plus d’informations, consultez le comportement de session Azure AD B2C.

Pour déconnecter l’utilisateur, redirigez l’utilisateur vers celui end_session_endpoint répertorié dans le document de métadonnées OpenID Connect décrit précédemment :

GET https://{tenant}.b2clogin.com/{tenant}.onmicrosoft.com/{policy}/oauth2/v2.0/logout?post_logout_redirect_uri=https%3A%2F%2Fjwt.ms%2F

Paramètre	Obligatoire	Descriptif
{locataire}	Oui	Nom de votre locataire Azure AD B2C. Si vous utilisez un domaine personnalisé, remplacez-le `tenant.b2clogin.com` par votre domaine, par `fabrikam.com`exemple .
{politique}	Oui	Flux utilisateur que vous spécifiez dans la demande d’autorisation. Par exemple, si l’utilisateur s’est connecté avec le `b2c_1_sign_in` flux utilisateur, spécifiez `b2c_1_sign_in` dans la demande de déconnexion.
id_token_hint	Non	Jeton d’ID précédemment émis pour passer au point de terminaison de déconnexion comme indicateur de la session authentifiée actuelle de l’utilisateur final avec le client. Le `id_token_hint` garantit que le `post_logout_redirect_uri` est une URL de réponse enregistrée dans vos paramètres d'application Azure AD B2C. Pour en savoir plus, consultez Sécuriser la redirection de déconnexion.
client_id	Non*	ID d’application attribué au portail Azure à votre application. * Cela est nécessaire lors de l'utilisation de la configuration SSO d'isolation `Application` et lorsque l'option Exiger un jeton d'ID est activée dans la demande de déconnexion est définie sur `No`.
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. Sauf si vous fournissez un `id_token_hint`, vous ne devez pas inscrire cette URL en tant qu’URL de réponse dans vos paramètres d’application Azure AD B2C.
état	Non	Si vous incluez un `state` paramètre dans la demande d’autorisation, le serveur d’autorisation retourne la même valeur dans la réponse au `post_logout_redirect_uri`. L’application doit vérifier que la `state` valeur dans la demande et la réponse sont identiques.

Lors d’une demande de déconnexion, Azure AD B2C invalide la session basée sur les cookies Azure AD B2C et tente de se déconnecter des fournisseurs d’identité fédérés. Pour plus d’informations, consultez Déconnexion unique.

Sécuriser la redirection de déconnexion

Après la déconnexion, l’utilisateur est redirigé vers l’URI que vous spécifiez dans le post_logout_redirect_uri paramètre, quelles que soient les URL de réponse que vous spécifiez pour l’application. Toutefois, si un jeton d’ID valide id_token_hint est passé et que le jeton d’ID requis dans les demandes de déconnexion est activé, Azure AD B2C vérifie que la valeur correspond post_logout_redirect_uri à l’une des URI de redirection configurés de l’application avant d’effectuer la redirection. Si aucune URL de réponse correspondante n’a été configurée pour l’application, un message d’erreur s’affiche et l’utilisateur n’est pas redirigé.

Pour définir le jeton d’ID requis dans les demandes de déconnexion, consultez Configurer le comportement de session dans Azure Active Directory B2C.

En savoir plus sur la session Azure AD B2C.

Partager via

Connexion web avec OpenID Connect dans Azure Active Directory B2C