Partager via

Personnaliser les jetons

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 allez découvrir les informations que vous pouvez recevoir dans les jetons et comment personnaliser les jetons. Ces bonnes pratiques pour les développeurs Confiance Zéro améliorent la flexibilité et le contrôle tout en augmentant la sécurité des applications 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 différents rôles d’utilisateur, niveaux d’accès et fonctionnalités 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 inclure des données d’autorisation dans le jeton à partir de l’ID Microsoft Entra.

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 personnalisation de jeton ou ajouts de code.

Les professionnels de l’informatique peuvent empêcher l’émission de jetons à n’importe quelle application dans le locataire en utilisant le paramètre 'attribution d’utilisateur requise'. Cette approche garantit que seul un ensemble d’utilisateurs peut se connecter à l’application. Sans cet indicateur, tous les utilisateurs d’un locataire 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 d’application.
  • Modifiez le comportement des revendications retournées par la plateforme d’identités Microsoft dans les jetons.
  • Ajouter et accéder à des revendications personnalisées pour votre application.

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

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

Stratégies de mappage de 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 de revendications modifie les revendications 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 des revendications correspond à l'application d'entreprise ou au principal de service de cette application. Chaque locataire peut avoir son propre mappage de revendications.

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

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

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

Personnalisation des jetons liés au plan

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 utilisé 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.

Le 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

Lorsque 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 des définitions de rôle d’application pour vos applications et comment 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

  • Last updated on