Appel d’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 allez apprendre à 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.

Quand une API (nous allons l’appeler comme API d’origine) appelle une autre API, il est essentiel que l’API que nous appelons (nous l’appellerons en tant qu’API en aval) suit 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 à gauche et l’API d’origine à droite.

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. Composants du diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente, deux formes hexagonales étiquetées « ID » et « A » qui représentent les jetons d’ID et d’accès. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes de gauche aux formes de droite.

L’application cliente a acquis un jeton d’accès permission déléguée (indiqué par la forme du 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 ci-dessous 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. Premiers composants de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente, deux formes hexagonales étiquetées « ID » et « A » qui représentent les jetons d’ID et d’accès. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes de gauche aux formes de droite. Deuxième titre du diagramme : l’application cliente donne le jeton d’accès à l’API d’origine. Deuxième composant de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. À gauche, une étiquette de forme carrée est « Autorisation requise ». À gauche est une forme hexagonale intitulée « A » qui représente un jeton d’accès. Une flèche relie les formes de gauche aux formes de droite.

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 va continuer et traiter la demande 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 donne le jeton d’accès à l’API d’origine. Premiers composants de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. À gauche, une étiquette de forme carrée est « Autorisation requise ». Sur sa gauche est une forme hexagonale intitulée « A » qui représente un jeton d’accès. Une flèche relie les formes de gauche aux formes de droite. 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. Deuxième composant de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche aux formes de droite. Au-dessus de la flèche, à droite et en dessous de la forme cloud, est une forme hexagonale intitulée « A » qui représente un jeton d’accès.

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. Premiers composants de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. Au-dessus de la flèche, à gauche et en dessous de la forme cloud, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. Deuxième titre du diagramme : l’API d’origine ne peut pas utiliser le jeton pour appeler l’API en aval. Deuxième composant de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. Au-dessus de la flèche, à gauche et en dessous de la forme cloud, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes du milieu aux formes de droite.

L’API d’origine revient à Microsoft Entra ID

Dans l’animation ci-dessous, 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. Premiers composants de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. Au-dessus de la flèche, à gauche et en dessous de la forme cloud, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes du milieu aux formes de droite. 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. Deuxième composant de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. Au-dessus de la flèche, à gauche et en dessous de la forme cloud, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. Au-dessus des formes d’API d’origine, une flèche les connecte à la forme cloud Microsoft Entra. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes du milieu aux formes de droite.

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. Premiers composants de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. Au-dessus de la flèche, à gauche et en dessous de la forme cloud, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. Au-dessus des formes d’API d’origine, une flèche les connecte à la forme cloud Microsoft Entra. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes du milieu aux formes de droite. 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. Deuxième composant de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. Au-dessus des formes d’API d’origine, une flèche les connecte à la forme cloud Microsoft Entra. À gauche de cette flèche, à gauche et en dessous de la forme cloud, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. Sous le jeton d’accès est une forme clé. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes du milieu aux formes de droite.

Microsoft Entra ID vérifiera des é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 correct, 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. Premiers composants de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. Au-dessus des formes d’API d’origine, une flèche les connecte à la forme cloud Microsoft Entra. À gauche de cette flèche, à gauche et en dessous de la forme cloud, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. Sous le jeton d’accès est une forme clé. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes du milieu aux formes de droite. 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. Deuxième composant de diagramme : une représentation d’un cloud apparaît dans le centre supérieur de la diapositive englobant une icône Microsoft Entra ID. En bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. Au-dessus des formes d’API d’origine, une flèche les connecte à la forme cloud Microsoft Entra. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes du milieu aux formes de droite. Au-dessus de cette flèche, à droite des formes d’API d’origine, est une forme hexagonale intitulée « A » qui représente un jeton d’accès.

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

L’animation ci-dessous illustre le processus de flux On-Behalf-Of (OBO) qui permet à une API de continuer à avoir le contexte utilisateur tel qu’il 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. Premiers composants du diagramme : en bas à gauche, une forme de rectangle représente l’application cliente. Sous le rectangle de l’application cliente est une forme hexagonale intitulée « ID » qui représente un jeton d’ID. Dans le milieu inférieur, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. Une flèche relie les formes de gauche à celles du milieu. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes du milieu aux formes de droite. Au-dessus de cette flèche, à droite des formes d’API d’origine, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. 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. Deuxième composant de diagramme : en bas à gauche, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes de gauche aux formes de droite. Au-dessus de cette flèche, à droite des formes d’API d’origine, est une forme hexagonale intitulée « A » qui représente un jeton d’accès.

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 aura la revendication d’audience appropriée (aud) 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. Premiers composants de diagramme : en bas à gauche, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes de gauche aux formes de droite. Au-dessus de cette flèche, à droite des formes d’API d’origine, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. 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. Deuxième composant de diagramme : en bas à gauche, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes de gauche aux formes de droite. Au-dessus de cette flèche, à gauche de la forme Autorisation requise, est une forme hexagonale intitulée « A » qui représente un jeton d’accès.

Le jeton inclut les étendues pour le consentement accordé et l’identité de l’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 souhaiterez utiliser le compte de flux 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 sera en mesure de 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. Premiers composants de diagramme : en bas à gauche, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. À gauche, une étiquette de forme carrée est « Autorisation requise ». Une flèche relie les formes de gauche aux formes de droite. Au-dessus de cette flèche, à gauche de la forme Autorisation requise, est une forme hexagonale intitulée « A » qui représente un jeton d’accès. 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 sera en mesure de répondre correctement. Deuxième composant de diagramme : en bas à gauche, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API d’origine. En bas à droite, une icône en forme de cube, une forme cloud et une icône mondiale représentent l’API en aval. Une flèche relie les formes de gauche aux formes de droite. Au-dessus de cette flèche, à gauche des formes d’API en aval, est une forme hexagonale intitulée « A » qui représente un jeton d’accès.

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.
• La personnalisation des jetons décrit les informations que vous pouvez recevoir dans les jetons Microsoft Entra et comment personnaliser des jetons pour améliorer la flexibilité et le contrôle tout en augmentant la sécurité de l’application confiance zéro 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.