Appeler une API à partir d’une autre API

Comment, en tant que développeur, assurez-vous Confiance Zéro quand vous avez une API qui doit appeler une autre API ? Dans cet article, vous apprenez à développer en toute sécurité votre application lorsqu’elle fonctionne pour le compte d’un utilisateur.

Lorsqu’un utilisateur pilote l’interface utilisateur d’une application, l’application peut utiliser une permission déléguée afin que l’API sache quel utilisateur au nom de l’application fonctionne. Il inspecte la revendication d’objet (sub) ou les revendications d’ID d’objet (oid) et d’ID de locataire (tid) dans le jeton d’accès que l’application fournit lors de l’appel de l’API. L’API ne s’appuie pas sur l’application non approuvée, qui n’est qu’un appel provenant de quelque part sur le réseau. Au lieu de cela, il valide le jeton pour s’assurer que l’API ne fonctionne que pour le compte de l’utilisateur de l’application vérifié par l’ID Microsoft Entra.

Lorsqu’une API (appelée API d’origine) en appelle une autre, il est essentiel que l’API que nous appelons (appelée API en aval) suive le processus de validation. L’API en aval ne peut pas s’appuyer sur une source réseau non approuvée. Il doit obtenir l’identité de l’utilisateur à partir d’un jeton d’accès correctement validé.

Si l’API en aval ne suit pas le processus de validation approprié, l’API en aval doit s’appuyer sur l’API d’origine pour fournir l’identité de l’utilisateur d’une autre manière. L’API en aval peut utiliser incorrectement une autorisation d’application pour effectuer l’opération. Ensuite, l’API d’origine devient alors la seule autorité sur laquelle les utilisateurs peuvent réaliser ce qui se passe contre l’API en aval. L’API d’origine peut intentionnellement (ou non) permettre à un utilisateur d’accomplir une tâche qu’il ne peut pas accomplir autrement. Par exemple, un utilisateur peut modifier les détails d’un autre utilisateur ou lire et mettre à jour des documents auxquels l’utilisateur n’est pas autorisé à accéder. Une validation incorrecte peut entraîner des problèmes de sécurité graves.

Pour une meilleure sécurité, l’API d’origine acquiert un jeton d’accès de permission déléguée à fournir à l’API en aval lorsque l’API d’origine effectue l’appel. Voyons comment cela fonctionne.

1. L’application cliente acquiert le jeton d’accès pour appeler l’API d’origine. L’application cliente acquiert un jeton d’accès d’autorisation délégué à l’API d’origine. Le jeton d’accès de permission déléguée lui permet de fonctionner pour le compte de l’utilisateur pour appeler l’API d’origine qui nécessite une autorisation.
2. L’application cliente donne un jeton d’accès à l’API d’origine. L’application cliente donne le jeton d’accès à l’API d’origine. L’API d’origine valide et inspecte entièrement le jeton d’accès pour déterminer l’identité de l’utilisateur de l’application cliente.
3. L’API d’origine effectue la validation et l’application du jeton. Une fois que l’application cliente a accordé le jeton d’accès à l’API d’origine, celle-ci effectue la validation et l’application du jeton. Si tout est bon, l’API continue et sert la demande pour l’application cliente.
4. L’API d’origine ne peut pas utiliser le jeton d’accès pour appeler l’API en aval. L’API d’origine souhaite appeler une API en aval. Toutefois, l’API d’origine ne peut pas utiliser le jeton d’accès pour appeler l’API en aval.
5. L’API d’origine revient à Microsoft Entra ID. L’API d’origine doit revenir à l’ID Microsoft Entra. Il a besoin d’un jeton d’accès pour appeler l’API en aval pour le compte de l’utilisateur. L’API d’origine fournit le jeton qu’elle a reçu de l’application cliente et les informations d’identification du client de l’API d’origine.
6. Microsoft Entra ID effectue des vérifications. Microsoft Entra ID vérifie les éléments tels que le consentement ou l’application de l’accès conditionnel. Vous devrez peut-être revenir à votre client appelant et fournir une raison de ne pas pouvoir obtenir le jeton. En règle générale, vous utilisez un processus de défi de revendications pour revenir à l’application appelante avec des informations concernant le consentement non reçu (par exemple, être lié aux stratégies d’accès conditionnel). Si tout est bon, Microsoft Entra ID émet un jeton d’accès à l’API d’origine pour appeler l’API en aval pour le compte de l’utilisateur.
7. L’API d’origine dispose d’un contexte utilisateur avec le flux On-Behalf-Of. Le processus de fluxBehalf-Of actif (OBO) permet à une API de continuer à avoir le contexte utilisateur lorsqu’elle appelle l’API en aval.
8. L’API d’origine appelle l’API en aval. Appelez l’API en aval. Le jeton reçu par l’API en aval a la revendication d’audience (aud) appropriée qui indique l’API en aval. Le jeton inclut les étendues pour le consentement accordé et l’identité d’utilisateur d’application d’origine. L’API en aval peut implémenter correctement des autorisations effectives pour s’assurer que l’utilisateur identifié a l’autorisation d’accomplir la tâche demandée. Vous souhaitez utiliser le flux OBO pour acquérir des jetons pour qu’une API appelle une autre API pour vous assurer que le contexte utilisateur passe à toutes les API en aval.

Meilleure option : l’API d’origine effectue un flux On-Behalf-Of

La meilleure option consiste pour l’API d’origine à effectuer un fluxBehalf-Of (OBO). Si l’API en aval reçoit le jeton correct, elle peut répondre correctement. Lorsqu’une API agit pour le compte d’un utilisateur et doit appeler une autre API, l’API doit utiliser OBO pour acquérir un jeton d’accès de permission déléguée pour appeler l’API en aval pour le compte de l’utilisateur. Les API ne doivent jamais utiliser les autorisations d’application pour appeler des API en aval lorsque l’API agit pour le compte d’un utilisateur.

Étapes suivantes

• Les flux d’authentification de plateforme d’identités Microsoft et les scénarios d’application décrivent les flux d’authentification et les scénarios d’application dans lesquels ils sont utilisés.
• API Protection décrit les meilleures pratiques pour protéger votre API par le biais de l'enregistrement, de la définition des autorisations et du consentement, et de l'application de l'accès pour atteindre vos objectifs de confiance zéro.
• Exemple d'API protégée par le cadre de consentement d’identité Microsoft vous aide à concevoir des stratégies de permissions d'application à moindre privilège pour une meilleure expérience utilisateur.
• Personnaliser les jetons décrit les informations que vous pouvez recevoir dans les jetons Microsoft Entra. Il explique comment personnaliser des jetons afin 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.
• Les API personnalisées sécurisées avec le module Microsoft Identity Learn expliquent comment sécuriser une API web avec l’identité Microsoft et comment l’appeler à partir d’une autre application.
• Les meilleures pratiques de sécurité pour les propriétés d’application décrivent l’URI de redirection, les jetons d’accès, les certificats et les secrets, l’URI de l’ID d’application et la propriété de l’application.
• Les bibliothèques d'authentification de la Plateforme d’identités Microsoft décrivent la prise en charge de la bibliothèque d'authentification Microsoft pour différents types d'applications.