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

  • Article

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

Notes

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 des 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

La revendication aud identifie l’audience ciblée du jeton. 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 n’est que la première étape, et les vérifications sur le sujet et l’acteur décrits dans cet article sont toujours nécessaires. Si votre intention est d’autoriser tous les utilisateurs d’un locataire, il est vivement recommandé d’ajouter explicitement ces utilisateurs à un groupe et de les autoriser sur la base de ce groupe. Par exemple, en vérifiant uniquement l’ID de locataire et la présence d’une revendication oid, votre API peut autoriser par inadvertance tous les principaux de service de ce locataire en plus des 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 des revendications 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.

Vous pouvez également utiliser les revendications roles, groups ou wids pour déterminer si le sujet a l’autorisation d’effectuer une opération, bien qu’il ne s’agisse pas d’une liste exhaustive de toutes les façons dont un sujet peut obtenir 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 des administrateurs client ou parfois des utilisateurs, ce qui les rend inadaptées aux décisions d’autorisation. Elles ne sont utilisables qu’à 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.

Notes

Une application peut gérer des jetons d’application uniquement (requêtes provenant d’applications sans utilisateurs, telles que des applications démon) et vouloir autoriser une application spécifique sur plusieurs locataires, plutôt que des ID individuels de principaux de service. 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