Partager via

Personnaliser les jetons

  • Article

En tant que développeur, votre interaction principale avec Microsoft Entra ID consiste à demander un jeton pour identifier l’utilisateur. Vous demandez également un jeton pour obtenir l’autorisation d’appeler une API web. Le jeton d’API web détermine ce que cette API peut faire lorsqu’elle effectue une demande particulière. Dans cet article, vous découvrez les informations que vous pouvez recevoir dans les jetons, ainsi que la façon dont vous pouvez personnaliser les jetons. Ces meilleures pratiques de développement confiance zéro permettent d’améliorer la flexibilité et le contrôle tout en augmentant la sécurité de l’application avec des privilèges minimum.

Vos raisons de personnaliser vos jetons d’application dépendent du processus que vous utilisez pour générer une autorisation plus granulaire dans vos applications et API. Par exemple, vous pouvez avoir des rôles d’utilisateur, niveaux d’accès et fonctionnalités différents dans votre application qui s’appuient sur des informations provenant de jetons.

L’API Microsoft Graph fournit un ensemble robuste d’informations et de données d’annuaire dans Microsoft 365. Vous pouvez développer un système d’autorisation affiné et riche en utilisant les données dans Microsoft Graph. Par exemple, vous pouvez accéder à des informations à partir de l’appartenance au groupe de l’utilisateur, des données de profil détaillées, SharePoint et Outlook à utiliser dans vos décisions d’autorisation. Vous pouvez également inclure des données d’autorisation dans le jeton à partir de Microsoft Entra ID.

Autorisation au niveau de l’application

Il est possible pour les professionnels de l’informatique d’ajouter une autorisation au niveau de l’application sans personnaliser le jeton ni ajouter de code au développeur.

Les professionnels de l’informatique peuvent empêcher l’émission de jetons à n’importe quelle application du client à l’aide de l’indicateur d’attribution d’utilisateur requis pour s’assurer que seul un ensemble d’utilisateurs est en mesure de se connecter à l’application. Sans cet indicateur, tous les utilisateurs d’un client peuvent accéder à l’application. Avec cet indicateur, seuls les utilisateurs et les groupes affectés peuvent accéder à l’application. Lorsqu’un utilisateur affecté accède à l’application, l’application reçoit un jeton. Si l’utilisateur n’a pas d’affectation, l’application ne reçoit pas de jeton. N’oubliez pas de toujours gérer correctement les demandes de jetons qui ne reçoivent pas de jetons.

Méthodes de personnalisation des jetons

Il existe deux façons de personnaliser les jetons : les revendications facultatives et le mappage des revendications.

Revendications facultatives

Les revendications facultatives spécifient les revendications que vous souhaitez que Microsoft Entra ID envoie à votre application dans des jetons. Vous pouvez utiliser des revendications facultatives pour :

  • Sélectionnez d'autres revendications à inclure dans vos jetons de candidature.
  • Modifier le comportement des revendications que la Plateforme d’identités Microsoft renvoie en jetons.
  • Ajouter et accéder à des revendications personnalisées pour votre application.

Les revendications facultatives se bloquent de l’objet d’inscription d’application avec un schéma défini. Ils s’appliquent à l’application, quel que soit l’endroit où elle était en cours d’exécution. Lorsque vous écrivez une application multilocataire, les revendications facultatives fonctionnent bien, car elles sont cohérentes dans chaque locataire dans Microsoft Entra ID. Par exemple, une adresse IP n’est pas spécifique au client, tandis qu’une application a une adresse IP.

Par défaut, les utilisateurs invités d’un client peuvent également se connecter à votre application. Si vous souhaitez bloquer les utilisateurs invités, optez pour la revendication facultative (acct). S’il s’agit de 1, l’utilisateur a une classification d’invité. Si vous souhaitez bloquer les invités, bloquez les jetons avec acct==1.

Stratégie de mappage des revendications

Dans Microsoft Entra ID, les objets de stratégie représentent des ensembles de règles sur des applications individuelles ou sur toutes les applications d'une organisation. Une stratégie de mappage des réclamations modifie les réclamations que Microsoft Entra ID émet dans les jetons pour des applications spécifiques.

Vous utilisez le mappage de revendications pour les informations spécifiques au locataire qui n’ont aucun schéma (par exemple, EmployeeID, DivisionName). Le mappage de revendications s’applique au niveau du principal de service que l’administrateur client contrôle. Le mappage de revendications correspond à l’application d’entreprise ou au principal de service de cette application. Chaque client peut avoir son propre mappage de revendications.

Si vous développez une application métier, vous pouvez examiner spécifiquement ce que fait votre client (quelles revendications spécifiques votre locataire a disponibles que vous pouvez utiliser dans votre jeton). Par exemple, si une organisation possède une propriété de nom de division d’un utilisateur (pas un champ standard dans Microsoft Entra ID) dans son Active Directory local, vous pouvez utiliser Microsoft Entra Connecter pour la synchroniser avec l’ID Microsoft Entra.

Vous pouvez utiliser l’un des attributs d’extension standard pour contenir ces informations. Vous pouvez définir votre jeton avec une revendication de nom de division que vous pouvez composer à partir de l’extension correspondante (même si elle ne s’applique pas à chaque locataire). Par exemple, une organisation place son nom de division dans l’attribut d’extension 13.

Avec le mappage de revendications, vous pouvez le faire fonctionner pour un autre locataire qui place son nom de division dans l’attribut sept.

Planifier la personnalisation des jetons

Le jeton que vous personnalisez dépend de votre type d’application : application cliente ou API. Il n’existe aucune différence dans ce que vous pouvez faire pour personnaliser votre jeton. Ce que vous pouvez placer dans le jeton est le même pour chacun d’entre eux. Le jeton que vous choisissez de personnaliser dépend du jeton consommé par votre application.

Personnaliser les jetons d’ID

Si vous développez une application cliente, vous personnalisez le jeton d’ID, car il s’agit du jeton que vous demandez pour identifier l’utilisateur. Un jeton appartient à votre application lorsque la revendication d’audience (aud) dans le jeton correspond à l’ID client de votre application. Pour une application cliente qui appelle des API, mais qui ne les implémente pas, veillez à personnaliser uniquement le jeton d’ID de votre application.

Les Portail Azure et l’API Microsoft Graph vous permettent également de personnaliser le jeton d’accès pour votre application, mais ces personnalisations n’ont aucun effet. Vous ne pouvez pas personnaliser un jeton d’accès pour une API que vous ne possédez pas. N’oubliez pas que votre application ne doit pas tenter de décoder ou d’inspecter un jeton d’accès que votre application cliente reçoit comme autorisation d’appeler une API.

Personnaliser les jetons d’accès

Si vous développez une API, vous personnalisez le jeton d’accès, car votre API reçoit des jetons d’accès dans le cadre de l’appel du client à votre API.

Les applications clientes personnalisent toujours le jeton d’ID qu’elles reçoivent pour identifier l’utilisateur. Les API personnalisent les jetons d’accès reçus par l’API dans le cadre de l’appel à l’API.

Groupes et rôles d'application

L’une des techniques d’autorisation les plus courantes consiste à baser l’accès sur l’appartenance au groupe d’un utilisateur ou les rôles attribués. Configurer les revendications de groupe et les rôles d’application dans les jetons vous montre comment configurer vos applications avec des définitions de rôle d’application et affecter des groupes de sécurité aux rôles d’application. Ces méthodes permettent d’améliorer la flexibilité et le contrôle tout en augmentant la sécurité confiance zéro de l’application avec des privilèges minimum.

Étapes suivantes