Partager via

Sécuriser des applications et des API par la validation des revendications

L’interaction avec des jetons est un élément essentiel de la génération d’applications afin d’autoriser des utilisateurs. Conformément au principe de Confiance Zéro pour l’accès à privilèges minimum, il est essentiel que des applications valident les valeurs de certaines revendications présentes dans le jeton d’accès lors de l’exécution de l’autorisation.

L’autorisation basée sur des revendications permet aux applications de vérifier que le jeton contient des valeurs correctes pour des éléments tels que le tenant, l’objet et l’intervenant présent dans le jeton. Cela dit, l’autorisation basée sur des revendications peut sembler complexe compte tenu des différentes méthodes à utiliser et des scénarios à suivre. Cet article vise à simplifier le processus d’autorisation basé sur des revendications afin de veiller à ce que vos applications respectent les pratiques les plus sécurisées.

Pour veiller à ce que votre logique d’autorisation soit sécurisée, vous devez valider les informations suivantes dans des revendications :

  • L’audience appropriée est spécifiée pour le jeton.
  • L’ID de tenant du jeton correspond à l’ID du tenant dans lequel les données sont stockées.
  • L’objet du jeton est approprié.
  • L’intervenant (application cliente) est autorisé.

Note

Les jetons d’accès sont validés uniquement dans les API web pour lesquelles ils ont été acquis par un client. Le client ne doit pas valider les jetons d’accès.

Pour plus d’informations sur les revendications mentionnées dans cet article, consultez Jetons d’accès de la plateforme d’identités Microsoft.

Valider l’audience

L’affirmation aud identifie le destinataire prévu du token. Avant de valider des revendications, vous devez toujours vérifier que la valeur de la revendication aud contenue dans le jeton d’accès correspond à l’API Web. La valeur peut dépendre de la façon dont le client a demandé le jeton. L’audience dans le jeton d’accès dépend du point de terminaison :

  • Pour des jetons v2.0, l’audience est l’ID client de l’API web. Il s’agit d’un GUID.
  • Pour des jetons v1.0, l’audience est l’un des URI appID déclarés dans l’API web qui valide le jeton. Par exemple, api://{ApplicationID} ou un nom unique commençant par un nom de domaine (si le nom de domaine est associé à un tenant).

Si vous souhaitez obtenir plus d’informations sur l’URI appID d’une application, consultez URI d’ID d’application.

Valider le tenant

Vérifiez toujours que le tid d’un jeton correspond à l’ID du tenant utilisé pour stocker des données avec l’application. Lorsque les informations d’une application sont stockées dans le contexte d’un locataire, elles ne doivent être consultées à nouveau que plus tard dans le même locataire. N’autorisez jamais l’accès aux données d’un locataire à partir d’un autre locataire.

La validation du locataire est la première étape, mais les vérifications sur le sujet et l’acteur décrits dans cet article sont toujours nécessaires. Si vous envisagez d’autoriser tous les utilisateurs d’un locataire, il est vivement recommandé d’ajouter explicitement ces utilisateurs dans un groupe et d’autoriser en fonction du groupe. Par exemple, en vérifiant uniquement l’ID de locataire et la présence d’une revendication oid, votre API peut par inadvertance autoriser toutes les principaux de service de ce locataire ainsi que les utilisateurs.

Valider l’objet

Déterminez si l’objet du jeton, tel que l’utilisateur (ou l’application elle-même pour un jeton d’application uniquement), est autorisé.

Vous pouvez vérifier la présence de réclamations spécifiques sub ou oid.

Ou,

Vous pouvez vérifier que le sujet appartient à un rôle ou un groupe approprié avec les revendications roles, scp, groups, wids. Par exemple, utilisez les valeurs de revendication immuables tid et oid comme clé combinée des données d’application et pour déterminer si l’accès doit être octroyé à un utilisateur.

Les roles, groups ou wids revendications peuvent également être utilisées pour déterminer si le sujet a l’autorisation d’effectuer une opération, bien qu’il ne s’agit pas d’une liste exhaustive de toutes les façons dont un sujet peut recevoir des autorisations. Par exemple, un administrateur peut avoir l’autorisation d’écrire dans une API, mais pas un utilisateur normal, ou l’utilisateur peut faire partie d’un groupe autorisé à effectuer une action. La revendication wid représente les rôles au niveau du locataire attribués à l’utilisateur à partir des rôles présents dans les rôles intégrés Microsoft Entra. Pour plus d’informations, consultez Rôles intégrés Microsoft Entra.

Avertissement

N’utilisez jamais de revendications telles que email, preferred_username ou unique_name pour stocker ou déterminer si l’utilisateur d’un jeton d’accès doit avoir accès aux données. Ces revendications ne sont pas uniques et peuvent être contrôlables par les administrateurs clients ou parfois par les utilisateurs, ce qui les rend inadaptés aux décisions d’autorisation. Ils sont utilisables uniquement à des fins d’affichage. N’utilisez pas non plus la revendication upn pour une autorisation. Bien que le nom d’utilisateur principal soit unique, il change souvent pendant la durée de vie d’un principal d’utilisateur, ce qui le rend peu fiable pour une autorisation.

Valider l’intervenant

Une application cliente agissant pour le compte d’un utilisateur (appelé intervenant) doit également être autorisée. Utilisez la revendication scp (étendue) pour vérifier que l’application est autorisée à effectuer une opération. Les autorisations dans scp doivent être limitées à ce dont l’utilisateur a réellement besoin et suivent les principes du moindre privilège.

Cependant, dans certains cas, scp n'est pas présent dans le jeton. Vous devez vérifier l’absence de la revendication scp pour les scénarios suivants :

  • Applications démon/autorisation d’application uniquement
  • Jetons d’ID

Si vous souhaitez obtenir plus d’informations sur les étendues et les autorisations, consultez Étendues et autorisations dans la plateforme d’identités Microsoft.

Note

Une application peut gérer des jetons uniquement pour les applications (requêtes provenant d’applications sans utilisateurs, telles que des applications de type démon) et vouloir autoriser une application spécifique sur plusieurs locataires, plutôt que des identifiants principaux de service individuels. Dans ce cas, la revendication appid (pour les jetons v1.0) ou la revendication azp (pour les jetons v2.0) peut être utilisée pour l’autorisation de l’objet. Toutefois, lors de l’utilisation de ces revendications, l’application doit vérifier que le jeton a été émis directement pour l’application en validant la revendication idtyp facultative. Seuls les jetons de type app peuvent être autorisés de cette façon, car des jetons d’utilisateur délégués peuvent potentiellement être obtenus par des entités autres que l’application.

Étapes suivantes