Scénario : Application démon appelant des API web

Ce scénario vous guide dans la création d’une application démon qui appelle des API web.

Vue d’ensemble

Votre application peut acquérir un jeton pour appeler une API web pour son propre compte (pas pour le compte d’un utilisateur). Ce scénario est utile pour les applications démon. Il utilise l’octroi d’informations d’identification du client OAuth 2.0 standard.

Voici quelques exemples de cas d’utilisation d’applications démon :

• Applications web utilisées pour provisionner ou administrer des utilisateurs ou pour effectuer des traitements par lots dans un annuaire
• Applications de bureau (comme des services Windows sur Windows ou des processus démon sur Linux) qui effectuent des traitements par lots, ou un service de système d’exploitation qui s’exécute en arrière-plan
• API web que ont besoin de manipuler des annuaires, pas des utilisateurs spécifiques.

Il existe un autre cas courant où des applications non-démon utilisent des informations d’identification du client, même quand elles agissent pour le compte d’utilisateurs. Cela se produit quand, pour des raisons techniques, elles ont besoin d’accéder à une API web ou à une ressource sous leur propre identité. L’accès aux secrets dans Azure Key Vault ou Azure SQL Database pour un cache en est un exemple.

Vous ne pouvez pas déployer une application daemon sur un appareil d’utilisateur standard, et un utilisateur normal ne peut pas accéder à une application daemon. Seul un ensemble limité d’administrateurs informatiques peut accéder à des appareils qui exécutent des applications daemon. Ainsi, un mauvais acteur ne peut pas accéder à une clé secrète client ou à un jeton à partir du trafic de l’appareil et agir pour le compte de l’application daemon. Le scénario d’application daemon ne remplace pas l’authentification de l’appareil.

Exemples d’applications non daemon :

• Application mobile qui accède à un service web pour le compte d’une application, mais pas au nom d’un utilisateur.
• Appareil IoT qui accède à un service web pour le compte d’un appareil, mais pas au nom d’un utilisateur.

Applications qui acquièrent un jeton pour leurs propres identités :

• Comme elles accèdent à des ressources indépendamment des utilisateurs, les applications clientes confidentielles doivent prouver leur identité. Les administrateurs de locataires de Microsoft Entra doivent approuver ces applications relativement sensibles.
• Applications qui ont inscrit un secret (mot de passe ou certificat d’application) auprès de Microsoft Entra ID. Ce secret est transmis lors de l’appel à Microsoft Entra ID pour obtenir un jeton.

Spécificités

Les utilisateurs ne peuvent pas interagir avec une application démon, car elle nécessite sa propre identité. Ce type d’application demande un jeton d’accès en utilisant son identité d’application et en présentant à Microsoft Entra son ID d’application, ses informations d’identification (mot de passe ou certificat) et un URI d’ID d’application. Une fois l’authentification réussie, le démon reçoit un jeton d’accès (et un jeton d’actualisation) de la plateforme d’identités Microsoft. Ce jeton est ensuite utilisé pour appeler l’API web (et est actualisé si nécessaire).

Étant donné que les utilisateurs ne peuvent pas interagir avec les applications démon, le consentement incrémentiel n’est pas possible. Toutes les autorisations d’API nécessaires doivent être configurées lors de l’inscription de l’application. Le code de l’application ne demande que des autorisations définies de manière statique. Cela signifie également que les applications démon ne prennent en charge le consentement incrémentiel.

Pour les développeurs, l’expérience de bout en bout pour ce scénario présente les aspects suivants :

• Les applications démon n’ont de sens que pour les locataires Microsoft Entra. Il n’aurait aucun sens à créer une application démon qui tente de manipuler des comptes personnels Microsoft. Si vous êtes un développeur d’applications métier, vous allez créer votre application démon dans votre locataire. Si vous êtes éditeur de logiciels indépendant, vous pouvez créer une application démon multilocataire. Chaque administrateur des locataires doit donner son consentement.
• Lors de l’inscription de l’application, l’URI de réponse n’est pas nécessaire. Partagez des secrets, des certificats ou des assertions signées avec Microsoft Entra ID. Vous devez également demander des autorisations d’application et obtenir le consentement d’un administrateur pour utiliser ces autorisations d’application.
• La configuration de l’application doit fournir les informations d’identification du client qui ont été partagées avec Microsoft Entra ID lors de l’inscription de l’application.
• L’étendue utilisée pour acquérir un jeton avec le flux d’informations d’identification client doit être une étendue statique.

Lectures recommandées

Si vous débutez dans la gestion des identités et des accès (IAM) avec OAuth 2.0 et OpenID Connect, voire simplement avec IAM sur la plateforme d’identité Microsoft, les articles suivants doivent figurer en bonne position dans votre liste de lectures.

Bien que ces lectures ne soient pas requises avant d’effectuer votre premier démarrage rapide ou de suivre votre premier tutoriel, elles couvrent des aspects fondamentaux de la plate-forme, et une bonne connaissance de ceux-ci vous aidera à mesure que vous créerez des scénarios plus complexes.

Étapes suivantes

Passez à l’article suivant de ce scénario, Inscription d’application.