Authentification Windows intégrée

Si votre application de bureau ou mobile s’exécute sur Windows et sur un ordinateur connecté à un domaine Windows (joint à Active Directory ou Microsoft Entra), il est possible d’utiliser l’authentification intégrée Windows (IWA) pour acquérir un jeton en mode silencieux. Aucune interface utilisateur n’est requise lorsque vous utilisez l’application.

final String AUTHORITY;
final String APP_ID;
String userName;
List<String> scopes;

PublicClientApplication app = PublicClientApplication.builder(APP_ID)
        .authority(AUTHORITY)
        .build();

IntegratedWindowsAuthenticationParameters parameters =
        IntegratedWindowsAuthenticationParameters.builder(scope, userName).build();

IAuthenticationResult future = app.acquireToken(parameters).get();

Contraintes

• Utilisateurs fédérés* uniquement, c’est-à-dire où l’authentification est fédérée à une autorité locale (ADFS par exemple) ou des scénarios hybrides où l’authentification transparente est activée. Les locataires purement cloud, où les utilisateurs sont directement dans Microsoft Entra ID, sans aucun Active Directory sous-jacent, ne peuvent pas utiliser ce flux.
• IWA ne contourne PAS la MFA (authentification multifacteur). Si l’authentification MFA est configurée, IWA peut échouer en cas de demande MFA exigée, car MFA a besoin d’une interaction utilisateur.

Celui-ci est difficile. IWA n’est pas interactif, mais 2FA nécessite une interactivité utilisateur. Vous n’avez pas le contrôle lorsque le fournisseur d’identité demande l’exécution de l’authentification 2FA, l’administrateur de locataire, si. D’après nos observations, l’authentification à deux facteurs est requise lorsque vous vous connectez depuis un autre pays/une autre région, lorsque vous n’êtes pas connecté via un VPN au réseau d’entreprise, et parfois même lorsque vous êtes connecté via un VPN. Ne vous attendez pas à un ensemble déterministe de règles, Microsoft Entra ID utilise l’IA pour apprendre en permanence si 2FA est nécessaire. Vous devez revenir à une invite utilisateur si l'IWA échoue.

• L’autorité transmise dans le PublicApplication doit être :

  • avec locataire (de la forme https://login.microsoftonline.com/{tenant}/, où tenant correspond soit au GUID représentant l'ID du locataire, soit à un domaine associé au locataire.
  • pour tous les comptes professionnels et scolaires (https://login.microsoftonline.com/organizations/)

  Les comptes personnels Microsoft ne sont pas pris en charge (vous ne pouvez pas utiliser les tenants /common ou /consumers)

• Étant donné que l’authentification Windows intégrée est un flux silencieux :

  • l’utilisateur de votre application doit avoir précédemment accepté d’utiliser l’application
  • ou l’administrateur du locataire doit avoir préalablement consenti à ce que tous les utilisateurs du locataire utilisent l’application.
  • Cela signifie que :
    • soit, en tant que développeur, vous avez cliqué sur le bouton Autoriser dans le portail Azure pour vous-même,
    • ou un administrateur de locataire a appuyé sur le bouton Accorder/révoquer le consentement de l’administrateur pour {domaine locataire} dans l’onglet Autorisations de l’API de l’inscription de l’application
    • ou vous avez fourni un moyen aux utilisateurs de donner leur consentement à l’application
    • ou vous avez fourni un moyen permettant à l'administrateur du locataire d'accorder le consentement pour l'application