Notes
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.
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 locataireb2c_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_post fragment . 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
etexp
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.
Contenu connexe
- En savoir plus sur la session Azure AD B2C.