Vue d’ensemble des jetons dans Azure Active Directory B2C

2025-05-06

Important

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

Azure Active Directory B2C (Azure AD B2C) émet différents types de jetons de sécurité, car il traite chaque flux d’authentification. Cet article décrit le format, les caractéristiques de sécurité et le contenu de chaque type de jeton.

Types de jetons

Azure AD B2C prend en charge les protocoles OAuth 2.0 et OpenID Connect, qui utilisent des jetons pour l’authentification et l’accès sécurisé aux ressources. Tous les jetons utilisés dans Azure AD B2C sont des jetons web JSON (JWT) qui contiennent des assertions d’informations sur le porteur et l’objet du jeton.

Les jetons suivants sont utilisés en communication avec Azure AD B2C :

Jeton d’ID : JWT qui contient des revendications que vous pouvez utiliser pour identifier les utilisateurs de votre application. Ce jeton est envoyé en toute sécurité dans les requêtes HTTP pour la communication entre deux composants de la même application ou service. Vous pouvez utiliser les revendications dans un jeton d’ID comme vous le souhaitez. Ils sont couramment utilisés pour afficher des informations de compte ou prendre des décisions de contrôle d’accès dans une application. Les jetons d’ID émis par Azure AD B2C sont signés, mais ils ne sont pas chiffrés. Lorsque votre application ou API reçoit un jeton d’ID, elle doit valider la signature pour prouver que le jeton est authentique. Votre application ou VOTRE API doivent également valider quelques revendications dans le jeton pour prouver qu’elle est valide. Selon les exigences du scénario, les revendications validées par une application peuvent varier, mais votre application doit effectuer certaines validations courantes des revendications dans chaque scénario.
Jeton d’accès : JWT qui contient des revendications que vous pouvez utiliser pour identifier les autorisations accordées à vos API. Les jetons d’accès sont signés, mais ils ne sont pas chiffrés. Les jetons d’accès sont utilisés pour fournir l’accès aux API et aux serveurs de ressources. Lorsque votre API reçoit un jeton d’accès, elle doit valider la signature pour prouver que le jeton est authentique. Votre API doit également valider quelques revendications dans le jeton pour prouver qu’elle est valide. Selon les exigences du scénario, les revendications validées par une application peuvent varier, mais votre application doit effectuer certaines validations courantes des revendications dans chaque scénario.
Jeton d’actualisation : les jetons d’actualisation sont utilisés pour acquérir de nouveaux jetons d’ID et des jetons d’accès dans un flux OAuth 2.0. Ils fournissent à votre application un accès à long terme aux ressources pour le compte des utilisateurs sans nécessiter d’interaction avec ces utilisateurs. Les jetons d’actualisation sont opaques pour votre application. Ils sont émis par Azure AD B2C et peuvent être inspectés et interprétés uniquement par Azure AD B2C. Ils ont une longue durée de vie, mais votre application ne doit pas être écrite dans l’attente qu’un jeton d’actualisation ait une durée déterminée. Les jetons d’actualisation peuvent être invalidés à tout moment pour différentes raisons. La seule façon pour votre application de savoir si un jeton d’actualisation est valide consiste à tenter de l’échanger en effectuant une demande de jeton à Azure AD B2C. Lorsque vous échangez un jeton d’actualisation pour un nouveau jeton, vous recevez un nouveau jeton d’actualisation dans la réponse du jeton. Enregistrez le nouveau jeton d’actualisation. Il remplace le jeton d’actualisation que vous avez utilisé précédemment dans la requête. Cette action permet de garantir que vos jetons d’actualisation restent valides tant que possible. Les applications monopages utilisant le flux de code d’autorisation avec PKCE ont toujours une durée de vie de jeton d’actualisation de 24 heures. En savoir plus sur les implications de sécurité des jetons d’actualisation dans le navigateur.

Points de terminaison

Une application inscrite reçoit des jetons et communique avec Azure AD B2C en envoyant des demandes à ces points de terminaison :

https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/authorize
https://<tenant-name>.b2clogin.com/<tenant-name>.onmicrosoft.com/<policy-name>/oauth2/v2.0/token

Les jetons de sécurité reçus par votre application à partir d’Azure AD B2C peuvent provenir des points de terminaison /authorize ou /token. Lorsque les jetons d’ID sont acquis à partir du :

point de terminaison /authorize, cela se fait à l'aide du flux implicite, souvent employé en cas d’ouverture de session sur des applications web JavaScript. Toutefois, si votre application utilise MSAL.js 2.0 ou version ultérieure, n’activez pas l’octroi de flux implicite dans votre inscription d’application, car MSAL.js 2.0+ prend en charge le flux de code d’autorisation avec PKCE.
point de terminaison /token, cela se fait à l'aide du flux de code confidentiel, qui cache le jeton au navigateur.

Réclamations

Lorsque vous utilisez Azure AD B2C, vous avez un contrôle précis sur le contenu de vos jetons. Vous pouvez configurer des flux utilisateur et des stratégies personnalisées pour envoyer certains ensembles de données utilisateur dans les revendications requises pour votre application. Ces revendications peuvent inclure des propriétés standard telles que displayName et emailAddress. Vos applications peuvent utiliser ces revendications pour authentifier en toute sécurité les utilisateurs et les demandes.

Les revendications dans les jetons d’ID ne sont pas retournées dans un ordre particulier. De nouvelles revendications peuvent être introduites dans des jetons d’ID à tout moment. Votre application ne doit pas s’interrompre à mesure que de nouvelles revendications sont introduites. Vous pouvez également inclure des attributs utilisateur personnalisés dans vos revendications.

Le tableau suivant répertorie les revendications que vous pouvez attendre dans les jetons d’ID et les jetons d’accès émis par Azure AD B2C.

Nom	Réclamation	Exemple de valeur	Descriptif
Public visé	`aud`	`00001111-aaaa-2222-bbbb-3333cccc4444`	Identifie le destinataire du jeton. Pour Azure AD B2C, l’audience est l’ID d’application. Votre application doit valider cette valeur et rejeter le jeton s’il ne correspond pas. L’audience est synonyme de ressource.
Émetteur	`iss`	`https://<tenant-name>.b2clogin.com/aaaabbbb-0000-cccc-1111-dddd2222eeee/v2.0/`	Identifie le service de jeton de sécurité (STS) qui construit et retourne le jeton. Il identifie également le répertoire dans lequel l’utilisateur a été authentifié. Votre application doit valider la revendication de l’émetteur pour vous assurer que le jeton provient du point de terminaison approprié.
Émis à	`iat`	`1438535543`	Heure à laquelle le jeton a été émis, représentée en heure epoch.
Heure d’expiration	`exp`	`1438539443`	Heure à laquelle le jeton n’est plus valide, représentée en heure epoch. Votre application doit utiliser cette revendication pour vérifier la validité de la durée de vie du jeton.
Pas avant	`nbf`	`1438535543`	Heure à laquelle le jeton est valide, représentée en heure epoch. Cette heure correspond généralement à l’heure à laquelle le jeton a été émis. Votre application doit utiliser cette revendication pour vérifier la validité de la durée de vie du jeton.
Version	`ver`	`1.0`	Version du jeton d’ID, telle que définie par Azure AD B2C.
Hachage de code	`c_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Un hachage de code est inclus dans un jeton d'identité uniquement lorsque le jeton est émis avec un code d'autorisation OAuth 2.0. Un hachage de code peut être utilisé pour valider l’authenticité d’un code d’autorisation. Pour plus d’informations sur l’exécution de cette validation, consultez la spécification OpenID Connect.
Hachage de jeton d’accès	`at_hash`	`SGCPtt01wxwfgnYZy2VJtQ`	Le hachage du jeton d’accès est inclus dans un jeton d’ID uniquement lorsque le jeton est émis conjointement avec un jeton d’accès OAuth 2.0. Un hachage de jeton d’accès peut être utilisé pour valider l’authenticité d’un jeton d’accès. Pour plus d’informations sur l’exécution de cette validation, consultez la spécification OpenID Connect
Valeur à usage unique	`nonce`	`12345`	La valeur à usage unique est une stratégie d’atténuation des attaques par relecture de jetons. Votre application peut spécifier une valeur à usage unique dans une demande d’autorisation à l’aide du paramètre de requête `nonce`. La valeur que vous fournissez dans la requête est émise sans aucune modification dans la revendication `nonce` du jeton d’ID. Cette revendication permet à votre application de vérifier la valeur par rapport à la valeur spécifiée sur la demande. Votre application doit effectuer cette validation pendant le processus de validation du jeton d’ID.
Sujet	`sub`	`aaaaaaaa-0000-1111-2222-bbbbbbbbbbbb`	Principal sur lequel portent les assertions d’informations du jeton, comme l’utilisateur d’une application. Cette valeur est immuable et ne peut pas être réattribuée ou réutilisée. Il peut être utilisé pour effectuer des vérifications d’autorisation en toute sécurité, par exemple lorsque le jeton est utilisé pour accéder à une ressource. Par défaut, la revendication de l’objet est remplie avec l’ID d’objet de l’utilisateur dans le répertoire.
Informations de référence sur la classe de contexte d’authentification	`acr`	Sans objet	Utilisé uniquement avec des stratégies plus anciennes.
Stratégie d’infrastructure d’approbation	`tfp`	`b2c_1_signupsignin1`	Nom de la stratégie utilisée pour acquérir le jeton d’ID.
Durée d’authentification	`auth_time`	`1438535543`	Heure à laquelle l’utilisateur a entré ses informations d’identification pour la dernière fois, représentée en heure epoch. Il n’existe aucune discrimination entre cette authentification étant une nouvelle connexion, une session d’authentification unique (SSO) ou un autre type de connexion. `auth_time` correspond à la dernière fois que l’application (ou l’utilisateur) a initié une tentative d’authentification auprès d'Azure AD B2C. La méthode utilisée pour l’authentification n’est pas différenciée.
Étendue	`scp`	`Read`	Autorisations accordées à la ressource pour un jeton d’accès. Plusieurs autorisations accordées sont séparées par un espace.
Partie autorisée	`azp`	`975251ed-e4f5-4efd-abcb-5f1a8f566ab7`	ID d’application de l’application cliente qui a lancé la requête.

Paramétrage

Les propriétés suivantes sont utilisées pour gérer les durées de vie des jetons de sécurité émis par Azure AD B2C :

Durées de vie des jetons Access &ID (minutes) : durée de vie du jeton du porteur OAuth 2.0 utilisé pour accéder à une ressource protégée. La valeur par défaut est de 60 minutes. La valeur minimale (inclusive) est de 5 minutes. La valeur maximale (inclusive) est de 1 440 minutes.
Durée de vie du jeton d’actualisation (jours) : période maximale avant laquelle un jeton d’actualisation peut être utilisé pour acquérir un nouveau jeton d’accès ou d’ID. La période concerne également l’acquisition d’un nouveau jeton d’actualisation si l’étendue offline_access a été accordée à votre application. La valeur par défaut est de 14 jours. Le minimum (inclusif) est un jour. La valeur maximale (inclusive) est de 90 jours.
Durée de vie de la fenêtre glissante du jeton d’actualisation (jours) : une fois cette période écoulée, l’utilisateur est obligé de se réauthentifier, quelle que soit la période de validité du jeton d’actualisation le plus récent acquis par l’application. Elle ne peut être fournie que si le commutateur est défini sur Bounded. Elle doit être supérieure ou égale à la valeur de durée de vie du jeton d’actualisation (jours). Si le commutateur est défini sur Aucune expiration, vous ne pouvez pas fournir de valeur spécifique. La valeur par défaut est 90 jours. Le minimum (inclusif) est un jour. La valeur maximale (inclusive) est de 365 jours.

Les cas d’usage suivants sont activés à l’aide de ces propriétés :

Autoriser un utilisateur à rester connecté à une application mobile indéfiniment, tant que l’utilisateur est continuellement actif sur l’application. Vous pouvez définir le paramètre Durée de vie de la fenêtre glissante du jeton d’actualisation (jours) sur Pas d’expiration dans votre flux d’utilisateur de connexion.
Répondez aux exigences de sécurité et de conformité de votre secteur en définissant les durées de vie des jetons d’accès appropriées.

Ces paramètres ne sont pas disponibles pour les flux utilisateur de réinitialisation de mot de passe.

Compatibilité

Les propriétés suivantes sont utilisées pour gérer la compatibilité des jetons :

Revendication de l’émetteur (iss) : cette propriété identifie le client Azure AD B2C qui a émis le jeton. La valeur par défaut est https://<domain>/{B2C tenant GUID}/v2.0/. La valeur de https://<domain>/tfp/{B2C tenant GUID}/{Policy ID}/v2.0/ inclut les ID pour le locataire Azure AD B2C et le flux d’utilisateur utilisé dans la demande de jeton. Si votre application ou bibliothèque a besoin d’Azure AD B2C pour être conforme à la spécification OpenID Connect Discovery 1.0, utilisez cette valeur.
Revendication d’objet (obj) : cette propriété identifie l’entité pour laquelle le jeton indique des informations. La valeur par défaut est ObjectID, qui remplit la sub revendication dans le jeton avec l’ID d’objet de l’utilisateur. La valeur Non prise en charge est fournie uniquement pour la compatibilité descendante. Nous vous recommandons de passer à ObjectID dès que vous êtes en mesure de le faire.
ID de stratégie représentant la revendication : cette propriété identifie le type de revendication dans lequel le nom de stratégie utilisé dans la requête de jeton est renseigné. La valeur par défaut est tfp. La valeur de acr n’est fournie que pour la compatibilité descendante.

Requête directe

Quand un parcours utilisateur démarre, Azure AD B2C reçoit un jeton d’accès d’un fournisseur d’identité. Azure AD B2C utilise ce jeton pour récupérer des informations sur l’utilisateur. Vous activez une revendication dans votre flux utilisateur pour transmettre le jeton aux applications que vous inscrivez dans Azure AD B2C. Votre application doit utiliser un flux utilisateur recommandé pour tirer parti de la transmission du jeton en tant que revendication.

Actuellement, Azure AD B2C prend uniquement en charge le passage du jeton d’accès des fournisseurs d’identité OAuth 2.0, notamment Facebook et Google. Pour tous les autres fournisseurs d’identité, la déclaration est retournée vide.

Vérification

Pour valider un jeton, votre application doit vérifier à la fois la signature et les revendications du jeton. De nombreuses bibliothèques open source sont disponibles pour valider les JWT, en fonction de votre langue préférée. Il est recommandé d’explorer ces options plutôt que d’implémenter votre propre logique de validation.

Valider la signature

Un JWT contient trois segments, un en-tête, un corps et une signature. Le segment de signature peut être utilisé pour valider l’authenticité du jeton afin qu’il puisse être approuvé par votre application. Les jetons Azure AD B2C sont signés à l’aide d’algorithmes de chiffrement asymétrique standard, tels que RSA 256.

L’en-tête du jeton contient des informations sur la clé et la méthode de chiffrement utilisée pour signer le jeton :

{
        "typ": "JWT",
        "alg": "RS256",
        "kid": "GvnPApfWMdLRi8PDmisFn7bprKg"
}

La valeur de la revendication alg est l’algorithme utilisé pour signer le jeton. La valeur de la revendication kid est la clé publique utilisée pour signer le jeton. À tout moment, Azure AD B2C peut signer un jeton à l’aide d’un ensemble de paires de clés publiques-privées. Azure AD B2C fait pivoter régulièrement l’ensemble de clés possible. Votre application doit être écrite pour gérer automatiquement ces modifications de clé. Une fréquence raisonnable pour vérifier les mises à jour des clés publiques utilisées par Azure AD B2C est toutes les 24 heures. Pour gérer les modifications inattendues des clés, votre application doit être écrite pour récupérer à nouveau les clés publiques si elle reçoit une valeur enfant inattendue.

Azure AD B2C est doté d'un point de terminaison de métadonnées OpenID Connect. À l’aide de ce point de terminaison, les applications peuvent demander 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. Votre locataire Azure AD B2C contient un document de métadonnées JSON pour chaque stratégie. Le document de métadonnées est un objet JSON qui contient plusieurs informations utiles. Les métadonnées contiennent jwks_uri, ce qui donne l’emplacement de l’ensemble de clés publiques utilisées pour signer des jetons. Cet emplacement est fourni ici, mais il est préférable d’extraire l’emplacement dynamiquement à l’aide du document de métadonnées et de l’analyse jwks_uri :

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/discovery/v2.0/keys

Le document JSON situé à cette URL contient toutes les informations de clé publique en cours d’utilisation à un moment particulier. Votre application peut utiliser la kid revendication dans l’en-tête JWT pour sélectionner la clé publique dans le document JSON utilisé pour signer un jeton particulier. Il peut ensuite effectuer la validation de signature à l’aide de la clé publique correcte et de l’algorithme indiqué.

Le document de métadonnées pour la stratégie B2C_1_signupsignin1 dans le locataire contoso.onmicrosoft.com se trouve à l’emplacement suivant :

https://contoso.b2clogin.com/contoso.onmicrosoft.com/b2c_1_signupsignin1/v2.0/.well-known/openid-configuration

Pour déterminer la stratégie utilisée pour signer un jeton (et où demander les métadonnées), vous avez deux options. Tout d’abord, le nom de la stratégie est inclus dans la revendication tfp (par défaut) ou acr (configurée) dans le jeton. Vous pouvez extraire les assertions du corps du JWT en décodant le corps en base 64 et en désérialisant la chaîne JSON résultante. La revendication tfp ou acr est le nom de la stratégie qui a été utilisée pour émettre le jeton. L’autre option consiste à encoder la stratégie dans la valeur du state paramètre lorsque vous émettez la requête, puis à la décoder pour déterminer la stratégie utilisée. L’une ou l’autre méthode est valide.

Azure AD B2C utilise l’algorithme RS256, qui est basé sur la spécification RFC 3447 . La clé publique se compose de deux composants : le module RSA (n) et l’exposant public RSA (e). Vous pouvez convertir n et e valeurs de manière programmatique dans un format de certificat pour la validation des jetons.

Une description de la façon d’effectuer la validation de signature est en dehors de l’étendue de ce document. De nombreuses bibliothèques open source sont disponibles pour vous aider à valider un jeton.

Valider les revendications

Lorsque vos applications ou API reçoivent un jeton d’ID, il doit également effectuer plusieurs vérifications sur les revendications dans le jeton d’ID. Les revendications suivantes doivent être vérifiées :

audience - Vérifie que le jeton d’ID était bien destiné à votre application.
pas avant et heure d’expiration : vérifie que le jeton d’ID n’a pas expiré.
émetteur : vérifie que le jeton a été émis à votre application par Azure AD B2C.
valeur à usage unique - Stratégie d’atténuation des attaques par relecture de jetons.

Pour obtenir la liste complète des validations que votre application doit effectuer, reportez-vous à la spécification OpenID Connect.

En savoir plus sur l’utilisation des jetons d’accès.