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. Elle inspecte les revendications de l’objet (sub) ou l’ID d’objet (oid) et les revendications ID de locataire (tid) dans le jeton d’accès fourni par l’application lors de l’appel de l’API. L’API ne s’appuie pas sur l’application non approuvée, qui est simplement un appel provenant d’un endroit sur le réseau. Au lieu de cela, il valide le jeton pour s’assurer que l’API fonctionne uniquement pour le compte de l’utilisateur de l’application vérifié par Microsoft Entra ID.

Lorsqu’une API (nous l’appelons API d’origine) appelle une autre API, il est essentiel que l’API que nous appelons (nous l’appelons API en aval) suive le processus de validation décrit ci-dessus. 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. L’API d’origine devient alors la seule autorité sur laquelle les utilisateurs peuvent obtenir les résultats obtenus par rapport à l’API en aval. L’API d’origine peut intentionnellement (ou involontairement) permettre à un utilisateur d’accomplir une tâche que l’utilisateur n’a pas pu 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’a pas l’autorisation d’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.

L’application cliente acquiert le jeton d’accès pour appeler l’API d’origine

Le diagramme suivant montre l’application cliente et l’API d’origine.

Titre du diagramme : l’application cliente a acquis un jeton d’accès pour appeler l’API d’origine. Sous-titre du diagramme : l’application cliente a un jeton d’accès « A » qui lui permet de travailler pour le compte de l’utilisateur identifié dans le jeton pour appeler l’API d’origine.

L’application cliente a acquis un jeton d’accès de permission déléguée (indiqué par la forme de pentagone avec l’étiquette « A ») à 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.

L’application cliente donne un jeton d’accès à l’API d’origine

L’animation suivante montre l’application cliente donnant 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.

Le diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : l’application cliente a acquis un jeton d’accès pour appeler l’API d’origine. Premier sous-titre du diagramme : l’application cliente a un jeton d’accès « A » qui lui permet de travailler au nom de l’utilisateur identifié dans le jeton pour appeler l’API d’origine. Deuxième titre du diagramme : l’application cliente donne le jeton d’accès à l’API d’origine.

L’API d’origine effectue la validation et l’application des jetons

L’animation suivante montre que, une fois que l’application cliente a donné le jeton d’accès à l’API d’origine, l’API d’origine effectue la validation et l’application des jetons. Si tout est bon, l’API continue et sert la demande pour l’application cliente.

Le diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : l’application cliente donne le jeton d’accès à l’API d’origine. Deuxième titre du diagramme : l’API d’origine effectue la validation et l’application des jetons. Si tout est bon, l’API continue et services la demande.

L’API d’origine ne peut pas utiliser le jeton d’accès pour appeler l’API en aval

L’animation suivante montre que l’API d’origine souhaite maintenant 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.

Le diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : l’API d’origine souhaite appeler une API en aval. Deuxième titre du diagramme : l’API d’origine ne peut pas utiliser le jeton pour appeler l’API en aval.

L’API d’origine revient à Microsoft Entra ID

Dans l’animation suivante, l’API d’origine doit revenir à Microsoft Entra ID. Il a besoin d’un jeton d’accès pour appeler l’API en aval pour le compte de l’utilisateur.

Le diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : l’API d’origine ne peut pas utiliser le jeton pour appeler l’API en aval. Deuxième titre du diagramme : l’API d’origine revient à l’ID Microsoft Entra. Deuxième sous-titre du diagramme : nécessite un jeton d’accès pour appeler l’API en aval pour le compte de l’utilisateur.

L’animation suivante montre l’API d’origine fournissant le jeton reçu par l’API d’origine de l’application cliente et les identifiants du client de l’API d’origine.

Le diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : l’API d’origine revient à Microsoft Entra ID. Premier sous-titre du diagramme : nécessite un jeton d’accès pour appeler l’API en aval pour le compte de l’utilisateur. Deuxième titre du diagramme : l’API d’origine revient à l’ID Microsoft Entra. Deuxième sous-titre du diagramme : fournit le jeton de l’application cliente et les identifiants de l’API d’origine.

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

Microsoft Entra ID effectue des contrôles

Dans l'animation suivante, Microsoft Entra ID effectue ses contrôles. 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.

Le diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : l’API d’origine revient à Microsoft Entra ID. Premier sous-titre du diagramme : fournit le jeton de l’application cliente et les identifiants de l’API d’origine. Deuxième titre du diagramme : Microsoft Entra ID vérifie l'accès conditionnel, le consentement, etc. Deuxième sous-titre du diagramme : l’API d’origine reçoit son propre jeton d’accès pour appeler l’API en aval pour le compte de l’utilisateur qui s’est connecté à l’application cliente.

L’API d’origine a un contexte utilisateur avec le flux On-Behalf-Of

L’animation suivante illustre le processus de flux On-Behalf-Of (OBO) qui permet à une API de continuer à avoir le contexte utilisateur alors qu’elle appelle l’API en aval.

Le diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : le processus de flux on-Behalf-Of permet à l’API d’origine de continuer à avoir un contexte utilisateur tel qu’il appelle l’API en aval. Deuxième titre du diagramme : le processus de flux on-Behalf-Of permet à l’API d’origine de continuer à avoir un contexte utilisateur tel qu’il appelle l’API en aval.

API d’origine appelle l’API en aval

Dans l’animation suivante, nous appelons 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 diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : le processus de flux on-Behalf-Of permet à l’API d’origine de continuer à avoir un contexte utilisateur tel qu’il appelle l’API en aval. Deuxième titre du diagramme : l’API en aval est appelée. Deuxième sous-titre du diagramme : jeton reçu par l’API en aval a des revendications appropriées pour identifier l’utilisateur de l’application cliente.

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

Cette dernière animation montre que la meilleure option est pour l’API d’origine pour effectuer un flux On-Behalf-Of (OBO). Si l’API en aval reçoit le jeton correct, elle peut répondre correctement.

Le diagramme animé montre deux diagrammes avec une transition de mouvement entre le premier diagramme et le deuxième diagramme. Premier titre du diagramme : l’API en aval est appelée. Premier sous-titre du diagramme : le jeton reçu par l’API en aval a des revendications appropriées pour identifier l’utilisateur de l’application cliente. Deuxième titre du diagramme : la meilleure option est pour que l’API d’origine effectue « au nom du flux On-Behalf-Of ». 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 pour 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 (utilisés pour les flux implicites), les certificats et les secrets, l’URI d’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.