Application de bureau qui appelle des API web : Inscription d'application

  • Article

Cet article porte sur les spécificités de l’inscription d’application pour une application de bureau.

Types de comptes pris en charge

Les types de compte pris en charge dans une application de bureau dépendent de l’expérience que vous souhaitez mettre en avant. En raison de cette relation, les types de compte pris en charge dépendent des flux que vous voulez utiliser.

Audience pour l’acquisition de jetons interactive

Si votre application de bureau utilise l’authentification interactive, vous pouvez connecter des utilisateurs depuis n’importe quel type de compte.

Audience pour les flux silencieux d’application de bureau

  • Pour utiliser l’authentification Windows intégrée ou un nom d’utilisateur et un mot de passe, votre application doit connecter des utilisateurs dans votre locataire, par exemple, si vous êtes développeur d’application métier. Ou bien, dans des organisations Microsoft Entra, votre application doit se connecter aux utilisateurs de votre propre locataire s’il s’agit d’un scénario de fournisseur de logiciel indépendant. Ces flux d’authentification ne sont pas pris en charge pour des comptes Microsoft personnels.
  • Si vous connectez des utilisateurs avec des identités de réseaux sociaux qui passent par une stratégie et une autorité entreprise-client (B2C), vous pouvez uniquement utiliser l’authentification interactive par mot de passe et nom d’utilisateur.

URI de redirection

Les URI de redirection à utiliser dans une application de bureau dépendent du flux que vous voulez utiliser.

Spécifiez ’URI de redirection de votre application en configurant les paramètres de plateforme de l’application dans Inscriptions d’applications dans le centre d’administration Microsoft Entra.

  • Pour les applications qui utilisent Web Authentication Manager (WAM), les URI de redirection ne doivent pas être configurés dans MSAL, mais ils doivent être configurés dans l'enregistrement de l'application.

  • Pour les applications qui utilisent l’authentification interactive :

    • Applications qui utilisent des navigateurs incorporés : https://login.microsoftonline.com/common/oauth2/nativeclient (Remarque : si votre application affiche une fenêtre contextuelle qui est généralement dépourvue de barre d’adresse, elle utilise le « navigateur incorporé ».)
    • Applications qui utilisent des navigateurs système : http://localhost (Remarque : si votre application ouvre le navigateur par défaut de votre système (par exemple, Edge, Chrome, Firefox, etc.) pour l’accès au portail de connexion Microsoft, elle utilise le « navigateur système ».)

    Important

    Comme meilleure pratique de sécurité, nous vous recommandons de définir explicitement https://login.microsoftonline.com/common/oauth2/nativeclient ou http://localhost comme URI de redirection. Certaines bibliothèques d’authentification comme MSAL.NET utilisent la valeur par défaut urn:ietf:wg:oauth:2.0:oob si aucun autre URI de redirection n’est spécifié, ce qui n’est pas recommandé. Ce paramètre par défaut sera mis à jour en tant que changement cassant dans la prochaine version majeure.

  • Si vous générez une application Objective-C ou Swift native pour macOS, enregistrez l’URI de redirection en fonction de l’identificateur de bundle de votre application, au format suivant : msauth.<your.app.bundle.id>://auth. Remplacez <your.app.bundle.id> par l’identificateur de bundle de votre application.

  • Si vous générez une application Node.js Electron, utilisez un protocole de chaîne personnalisé au lieu d’un URI de redirection web ordinaire (https://) afin de gérer l’étape de redirection du flux d’autorisation, par exemple msal{Your_Application/Client_Id}://auth (par exemple : msal00001111-aaaa-2222-bbbb-3333cccc4444://auth). Le nom du protocole de chaîne personnalisé ne doit pas être simple à deviner et doit suivre les suggestions de la spécification OAuth 2.0 pour les applications natives.

  • Si votre application n’utilise que l’authentification Windows intégrée ou un mot de passe et un nom d’utilisateur, vous n’avez pas besoin d’inscrire d’URI de redirection pour votre application. Ces flux effectuent un aller-retour vers le point de terminaison de la plateforme d’identités Microsoft v2.0. Votre application ne sera pas rappelée sur un URI spécifique.

  • Pour différencier le flux de code d’appareil, l’authentification Windows intégrée et un mot de passe associé à un nom d’utilisateur d’une application cliente confidentielle à l’aide d’un flux d’informations d’identification client utilisé dans des applications démon, dont aucune ne requiert d’URI de redirection, configurez-la en tant qu’application cliente publique. Pour obtenir cette configuration :

    1. Dans le centre d’administration Microsoft Entra, sélectionnez votre application dans Inscriptions d’applications, puis sélectionnez Authentification.

    2. Dans Paramètres avancés>Autoriser les flux de clients publics>Activer les flux mobiles et de bureau suivants, sélectionnez Oui.

      Activer le paramètre client public dans le volet Authentification du portail Azure

Autorisations des API

Les applications de bureau appellent des API pour le compte de l’utilisateur connecté. Elles doivent demander des autorisations déléguées. Elles ne peuvent pas demander d’autorisations d’application, qui ne sont gérées que dans des applications démon.

Étapes suivantes

Passez à l’article suivant de ce scénario, Configuration du code de l’application.