Analyseur de jetons daccès

jetons d’accès sont un type de jeton de sécurité conçu pour l’autorisation, accordant l’accès à des ressources spécifiques au nom d’un utilisateur authentifié. Les informations contenues dans les jetons d’accès déterminent si un utilisateur a le droit d’accéder à une ressource particulière, comme les clés déverrouillant des portes spécifiques d’un bâtiment. Ces éléments d’information individuels qui constituent les jetons sont appelés revendications. Par conséquent, il s’agit d’informations d’identification sensibles qui présentent un risque de sécurité si elles ne sont pas gérées correctement. Les jetons d’accès diffèrent des jetons d’ID qui servent de preuve d’authentification.

Les jetons d’accès permettent aux clients d’appeler en toute sécurité des API Web protégées. Bien que les applications clientes puissent recevoir et utiliser des jetons d’accès, elles doivent être traitées comme des chaînes opaques. L’application cliente ne doit pas tenter de valider les jetons d’accès. Le serveur de ressources doit valider le jeton d’accès avant de l’accepter comme preuve d’autorisation. Le contenu du jeton est destiné uniquement à l’API, ce qui signifie que les jetons d’accès doivent être traités comme des chaînes opaques. À des fins de validation et de débogage uniquement , les développeurs peuvent décoder les JWT à l’aide d’un site tel que jwt.ms. Les jetons qu’une API Microsoft reçoit ne sont pas toujours des jetons JWT qui peuvent être décodés.

Les clients doivent utiliser les données de réponse du jeton qui sont renvoyées avec le jeton d’accès pour plus de détails sur ce qu’il contient. Lorsque le client demande un jeton d’accès, la plateforme d’identités Microsoft retourne également des métadonnées sur le jeton d’accès pour la consommation de l’application. Ces informations incluent le délai d’expiration du jeton d’accès et les étendues pour lesquelles il est valide. Ces données permettent à l’application d’effectuer une mise en cache intelligente des jetons d’accès sans avoir à analyser le jeton d’accès lui-même. Cet article explique les informations essentielles sur les jetons d’accès, y compris les formats, la propriété, les durées de vie et la façon dont les API peuvent valider et utiliser les revendications à l’intérieur d’un jeton d’accès.

Formats de jeton

Il existe deux versions de jetons d’accès disponibles dans la plateforme d’identités Microsoft : v1.0 et v2.0. Ces versions déterminent les revendications qui se trouvent dans le jeton et s’assurent qu’une API web peut contrôler le contenu du jeton.

Les API Web ont l’une des versions suivantes sélectionnées par défaut lors de l’inscription :

• v1.0 pour les applications Microsoft Entra uniquement. L’exemple suivant montre un jeton v1.0 (les clés sont modifiées et les informations personnelles sont supprimées, ce qui empêche la validation du jeton) :

• v2.0 pour les applications qui prennent en charge les comptes consommateurs. L’exemple suivant montre un jeton v2.0 (les clés sont modifiées et les informations personnelles sont supprimées, ce qui empêche la validation du jeton) :

Définissez la version des applications en fournissant la valeur appropriée au paramètre dans le manifeste de l’application. Les valeurs de et résultent en jetons v1.0, et la valeur de résultats en jetons v2.0.

Une

demande de jeton d’accès implique deux parties : le client, qui demande le jeton, et la ressource (API Web) qui accepte le jeton. La ressource à laquelle le jeton est destiné (son public ) est définie dans la revendication d’un jeton. Les clients utilisent le jeton, mais ne doivent pas le comprendre ou tenter de l’analyser. Les ressources acceptent le jeton.

L’identité Microsoft La plate-forme prend en charge l’émission de n’importe quelle version de jeton à partir de n’importe quel point de terminaison de version. Par exemple, lorsque la valeur de est , un client appelant le point de terminaison v1.0 pour obtenir un jeton pour cette ressource reçoit un jeton d’accès v2.0.

Les ressources sont toujours propriétaires de leurs jetons à l’aide de la revendication et sont les seules applications à pouvoir modifier les détails de leur jeton.

Durée de

vie du jeton La durée de vie par défaut d’un jeton d’accès est variable. Lorsqu’elle est émise, la plateforme d’identités Microsoft attribue une valeur aléatoire comprise entre 60 et 90 minutes (75 minutes en moyenne) comme durée de vie par défaut d’un jeton d’accès. La variante améliore la résilience du service en répartissant la demande de jeton d’accès sur une certaine période, ce qui permet d’éviter les pics horaires de trafic vers Microsoft Entra ID.

Les locataires qui n’utilisent pas l’accès conditionnel ont une durée de vie du jeton d’accès par défaut de deux heures pour les clients tels que Microsoft Teams et Microsoft 365.

Ajuster la durée de vie d’un jeton d’accès pour contrôler la fréquence d’expiration de la session d’application par l’application cliente et la fréquence à laquelle l’utilisateur doit s’authentifier à nouveau (en mode silencieux ou interactif). Pour remplacer la variation de durée de vie du jeton d’accès par défaut, utilisez la durée de vie du jeton configurable (CTL).

Appliquez la variation de durée de vie du jeton par défaut aux organisations qui ont activé l’évaluation d’accès continu (CAE). Appliquez la variation de durée de vie du jeton par défaut même si les organisations utilisent des stratégies CTL. La durée de vie par défaut du jeton à longue durée de vie est comprise entre 20 et 28 heures. Lorsque le jeton d’accès expire, le client doit utiliser le jeton d’actualisation pour acquérir silencieusement un nouveau jeton d’actualisation et un jeton d’accès.

Les organisations qui utilisent la fréquence de connexion par accès conditionnel (SIF) pour appliquer la fréquence des connexions ne peuvent pas remplacer la variation de durée de vie du jeton d’accès par défaut. Lorsque les organisations utilisent SIF, le temps écoulé entre les informations d’identification pour une Client est la durée de vie du jeton qui varie de 60 à 90 minutes plus l’intervalle de fréquence de connexion.

Voici un exemple de fonctionnement de la variation de durée de vie du jeton par défaut avec la fréquence de connexion. Supposons qu’une organisation définisse la fréquence de connexion pour qu’elle se produise toutes les heures. Lorsque la durée de vie du jeton varie de 60 à 90 minutes en raison de la variation de la durée de vie du jeton, l’intervalle de connexion réel se situe entre 1 heure et 2,5 heures.

Si un utilisateur avec un jeton avec une durée de vie d’une heure effectue une connexion interactive au bout de 59 minutes, il n’y a pas d’invite d’informations d’identification, car la connexion est inférieure au seuil SIF. Si un nouveau jeton a une durée de vie de 90 minutes, l’utilisateur ne verra pas d’invite d’informations d’identification avant une heure et demie. Lors d’une tentative de renouvellement en mode silencieux, Microsoft Entra ID nécessite une invite d’informations d’identification, car la durée totale de la session a dépassé le paramètre de fréquence de connexion de 1 heure. Dans cet exemple, la différence de temps entre les invites d’informations d’identification dues à l’intervalle SIF et à la variation de la durée de vie du jeton seraient de 2,5 heures.

Valider les jetons Toutes

les applications ne doivent pas valider les jetons. Ce n’est que dans des scénarios spécifiques que les applications doivent valider un jeton :

• les API Web doivent valider les jetons d’accès qui leur sont envoyés par un client. Ils ne doivent accepter que les jetons contenant l’une de leurs URI AppId en tant que revendication.
• Les applications web doivent valider les jetons d’ID qui leur sont envoyés à l’aide du navigateur de l’utilisateur dans le flux hybride, avant d’autoriser l’accès aux données d’un utilisateur ou d’établir une session.

Si aucun des scénarios décrits précédemment ne s’applique, il n’est pas nécessaire de valider le jeton. Les clients publics, tels que les applications natives, de bureau ou monopages, ne bénéficient pas de la validation des jetons d’ID, car l’application communique directement avec le fournisseur d’identités, où la protection SSL garantit la validité des jetons d’ID. Ils ne doivent pas valider les jetons d’accès, car ils sont destinés à la validation de l’API web, et non au client.

Les API et les applications web ne doivent valider que les jetons dont la revendication correspond à l’application. D’autres ressources peuvent avoir des règles de validation de jeton personnalisées. Par exemple, vous ne pouvez pas valider les jetons pour Microsoft Graph selon ces règles en raison de leur format propriétaire. La validation et l’acceptation de jetons destinés à une autre ressource sont un exemple du problème confus de l’adjoint.

Si l’application doit valider un jeton d’ID ou un jeton d’accès, elle doit d’abord valider la signature du jeton et de l’émetteur par rapport aux valeurs du document de découverte OpenID.

Le middleware Microsoft Entra dispose de fonctionnalités intégrées pour la validation des jetons d’accès, consultez des exemples pour en trouver un dans la langue appropriée. Il existe également plusieurs bibliothèques open source tierces disponibles pour la validation JWT. Pour plus d’informations sur Bibliothèques d’authentification et exemples de code, consultez les bibliothèques d’authentification. Si votre application web ou API web se trouve sur ASP.NET ou ASP.NET Core, utilisez Microsoft.Identity.Web, qui gère la validation pour vous.

Jetons v1.0 et v2.0

• Lorsque votre application/API web valide un jeton v1.0 ( claim ="1.0 »), elle doit lire le document de métadonnées OpenID Connect à partir du point de terminaison v1.0 (), même si l’autorité configurée pour votre API web est une autorité v2.0.
• Lorsque votre application/API web valide un jeton v2.0 ( claim ="2.0 »), elle doit lire le document de métadonnées OpenID Connect à partir du point de terminaison v2.0 (), même si l’autorité configurée pour votre API web est une autorité v1.0.

Les exemples suivants supposent que votre application valide un jeton d’accès v2.0 (et fait donc référence aux versions v2.0 des documents de métadonnées et des clés OIDC). Il suffit de supprimer le « /v2.0 » dans l’URL si Vous validez les jetons v1.0.

Validez l’émetteur

: OpenID Connect Core indique « L’identifiant de l’émetteur [...] DOIT correspondre exactement à la valeur de la créance iss (émetteur). Pour les applications qui utilisent un point de terminaison de métadonnées spécifique au locataire (comme ou ), c’est tout ce qui est nécessaire.

Microsoft Entra ID dispose d’une version du document indépendante du locataire disponible à l’adresse https://login.microsoftonline.com/common/v2.0/.well-known/openid-configuration. Ce point de terminaison renvoie une valeur d’émetteur . Les applications peuvent utiliser ce point de terminaison indépendant du locataire pour valider les jetons de chaque locataire avec les modifications suivantes :

1. Au lieu de s’attendre à ce que la revendication de l’émetteur dans le jeton corresponde exactement à la valeur de l’émetteur à partir des métadonnées, l’application doit remplacer la valeur des métadonnées de l’émetteur par l’ID de locataire qui est la cible de la demande actuelle, puis vérifier la correspondance exacte.

2. L’application doit utiliser la propriété renvoyée par le point de terminaison des clés pour restreindre l’étendue des clés.

   • Les clés qui ont une valeur d’émetteur comme peuvent être utilisées avec n’importe quel émetteur de jeton correspondant.
   • Les clés qui ont une valeur d’émetteur telle que ne doivent être utilisées qu’avec une correspondance exacte.
   Le

   point de terminaison de clé indépendant du locataire (https://login.microsoftonline.com/common/discovery/v2.0/keys) de Microsoft Entra renvoie un document tel que :

3. Les applications qui utilisent une revendication Microsoft Entra tenantid () comme limite d’approbation au lieu de la revendication d’émetteur standard doivent s’assurer que la revendication tenant-id est un GUID et que l’émetteur et l’identifiant de locataire correspondent.

L’utilisation de métadonnées indépendantes du locataire est plus efficace pour les applications qui acceptent des jetons de plusieurs locataires.

Valider la signature

Un JWT contient trois segments séparés par le caractère. Le premier segment est l’en-tête , le deuxième est le corps et le troisième est la signature . Utilisez le segment de signature pour évaluer l’authenticité du jeton.

Microsoft Entra ID émet des jetons signés à l’aide des algorithmes de chiffrement asymétrique standard, tels que RS256. L’en-tête du JWT contient des informations sur la clé et la méthode de chiffrement utilisées pour signer le jeton :

la revendication indique l’algorithme utilisé pour signer le jeton, tandis que la revendication indique Clé publique particulière qui a été utilisée pour valider le jeton.

À tout moment, Microsoft Entra ID peut signer un jeton d’ID à l’aide de l’un des nombreux ensembles de paires de clés publiques-privées. Microsoft Entra ID effectue une rotation périodique de l’ensemble possible de clés, alors écrivez l’application pour gérer automatiquement ces modifications de touches. Une fréquence raisonnable pour vérifier les mises à jour des clés publiques utilisées par Microsoft Entra ID est toutes les 24 heures.

Acquérez les données de clé de signature nécessaires à la validation de la signature à l’aide du document de métadonnées OpenID Connect situé à l’adresse suivante :

Les informations suivantes décrivent le document de métadonnées :

• Il s’agit d’un objet JSON qui contient plusieurs informations utiles, telles que l’emplacement des différents points de terminaison requis pour effectuer l’authentification OpenID Connect.
• Comprend un , qui donne l’emplacement de l’ensemble des clés publiques qui correspondent aux clés privées utilisées pour signer les jetons. La clé Web JSON (JWK) située à l’emplacement contient toutes les informations de clé publique utilisées à ce moment précis. La RFC 7517 décrit le format JWK. L’application peut utiliser la revendication dans l’en-tête JWT pour sélectionner la clé publique, à partir de ce document, qui correspond à la clé privée qui a été utilisée pour signer un jeton particulier. Il peut ensuite effectuer la validation de la signature à l’aide de la bonne clé publique et de l’algorithme indiqué.

La validation de la signature n’entre pas dans le cadre de ce document. Il existe de nombreuses bibliothèques open source disponibles pour aider à la validation des signatures si nécessaire. Cependant, le Identity Platform dispose d’une extension de signature de jeton aux normes, qui sont des clés de signature personnalisées.

Si l’application dispose de clés de signature personnalisées à la suite de l’utilisation de la fonctionnalité claims-mapping, ajoutez un paramètre de requête contenant l’ID de l’application. Pour la validation, utilisez that pointe vers les informations de clé de signature de l’application. Par exemple : contient un de .

Valider l’émetteur Les

applications Web validant les jetons d’ID et les API Web validant les jetons d’accès doivent valider l’émetteur du jeton (revendication) par rapport à

1. : l’émetteur disponible dans le document de métadonnées OpenID connect associé à la configuration de l’application (autorité). Le document de métadonnées à vérifier dépend de :
   • la version du jeton
   • les comptes pris en charge par votre application.
2. l’ID de locataire ( claim) du jeton,
3. le émetteur de la clé de signature.

Applications à locataire unique

OpenID Connect Core indique que « l’identifiant de l’émetteur [...] DOIT correspondre exactement à la valeur de la créance (de l’émetteur). Pour les applications qui utilisent un point de terminaison de métadonnées spécifique au locataire, tel que ou .

Les applications à locataire unique sont des applications qui prennent en charge :

• Comptes dans un annuaire organisationnel ( example-tenant-id uniquement) :
• Comptes Microsoft personnels uniquement : ( consumers étant un surnom pour le locataire 9188040d-6c67-4c5b-b112-36a304b66dad)

Applications multilocataires

Microsoft Entra ID prend également en charge les applications multilocataires. Ces applications prennent en charge :

• Comptes dans n’importe quel annuaire organisationnel (n’importe quel annuaire Microsoft Entra) :
• Comptes dans n’importe quel annuaire organisationnel (n’importe quel répertoire Microsoft Entra ID) et les comptes Microsoft personnels (par exemple, Skype, XBox) :

pour ces applications, Microsoft Entra ID expose les versions indépendantes du locataire du document OIDC au niveau et respectivement. Ces points de terminaison renvoient une valeur d’émetteur, qui est un modèle paramétré par le : . Les applications peuvent utiliser ces points de terminaison indépendants du locataire pour valider les jetons de chaque locataire avec les stipulations suivantes :

• Valider la clé de signature de l’émetteur
• émetteur Au lieu de s’attendre à ce que la revendication de l’émetteur dans le jeton corresponde exactement à la valeur de l’émetteur à partir des métadonnées, l’application doit remplacer la valeur des métadonnées de l’émetteur par l’ID de locataire qui est la cible de la demande actuelle, puis vérifiez la correspondance exacte (revendication du jeton).
• Vérifiez que la revendication est un GUID et que la revendication est de la forme où est la revendication exacte. Cette validation relie le locataire à l’émetteur et Revenons à la portée de la clé de signature créant une chaîne de confiance.
• Utilisation de la revendication lorsqu’ils localisent des données associées à l’objet de la demande. En d’autres termes, la revendication doit faire partie de la clé utilisée pour accéder aux données de l’utilisateur.

Valider l’émetteur de la clé

de

signature Les applications utilisant les métadonnées indépendantes du locataire v2.0 doivent valider l’émetteur de la clé de signature.

Document de clés et émetteur de clé de signature

Comme nous l’avons vu, à partir du document OpenID Connect, votre application accède aux clés utilisées pour signer les jetons. Il récupère le document de clés correspondant en accédant à l’URL exposée dans la propriété jwks_uri du document OpenIdConnect.

La valeur peut être remplacée par un GUID, un nom de domaine ou des organisations et des consommateurs communs .

exposée par Azure AD v2.0 contient, pour chaque clé, l’émetteur qui utilise cette clé de signature. Par exemple, le point de terminaison de clé « commun » indépendant du locataire renvoie un document tel que :

Validation de l’émetteur de la clé de signature

L’application doit utiliser la propriété du document de clés, associée à la clé utilisée pour signer le jeton, afin de restreindre la portée des clés :

• Les clés qui ont une valeur d’émetteur avec un GUID de type GUID ne doivent être utilisées que lorsque la revendication dans le jeton correspond exactement à la valeur.
• Les clés qui ont une valeur d’émetteur basée sur un modèle, par exemple, ne doivent être utilisées que lorsque la revendication du jeton correspond à cette valeur après avoir substitué la revendication du jeton à l’espace réservé.

L’utilisation de métadonnées indépendantes du locataire est plus efficace pour les applications qui acceptent des jetons de plusieurs locataires.

Voici

un pseudo-code qui récapitule comment valider l’émetteur et l’émetteur de la clé de signature :

1. Récupérer les clés à partir de l’URL des métadonnées configurées
2. Vérifier le jeton s’il est signé avec l’une des clés publiées, échouer si ce n’est pas le cas
3. Identifier la clé dans les métadonnées en fonction de l’en-tête enfant. Cochez la propriété « émetteur » attachée à la clé dans le document de métadonnées :

Contenu associé