Aplicación de escritorio que llama a las API web: adquisición de un token mediante la autenticación integrada de Windows

Para iniciar la sesión de un usuario de dominio en un dominio o en una máquina unida a Microsoft Entra, utilice la autenticación integrada de Windows (IWA).

Restricciones

  • La autenticación integrada de Windows está disponible solo para usuarios federados+, es decir, usuarios creados en Active Directory y respaldados por Microsoft Entra ID. Los usuarios creados directamente en Microsoft Entra ID sin respaldo de Active Directory, conocidos como usuarios administrados, no pueden utilizar este flujo de autenticación. Esta limitación no afecta al flujo de nombre de usuario y contraseña.

  • IWA no omite la autenticación multifactor (MFA). Si se ha configurado MFA, IWA podría producir un error si es necesario un desafío de MFA, porque MFA necesita interacción del usuario.

    IWA no es interactiva, pero MFA requiere interactividad del usuario. El usuario no es quien controla si el proveedor de identidades solicita que se realice MFA, sino el administrador de inquilinos. Por lo que se ha observado, MFA se requiere al iniciar sesión desde otro país o región, cuando no se está conectado a través de VPN a una red corporativa y, a veces, incluso cuando se está. No espere un conjunto determinista de reglas. Microsoft Entra ID usa inteligencia artificial para saber continuamente si se requiere MFA. Si se produce un error de IWA, recurra a un mensaje de usuario como la autenticación interactiva o el flujo de código de dispositivo.

  • La autoridad pasada en PublicClientApplicationBuilder debe ser:

    • Con inquilino con formato https://login.microsoftonline.com/{tenant}/, donde tenant es el GUID que representa el identificador de inquilino o un dominio asociado al inquilino.
    • Para cualquier cuenta profesional y educativa: https://login.microsoftonline.com/organizations/.
    • No se admiten cuentas personales de Microsoft. No se pueden usar inquilinos /common ni /consumers.
  • Debido a que la autenticación integrada de Windows es un flujo silencioso:

    • El usuario de la aplicación debe haber consentido anteriormente para usar la aplicación.
    • O bien, el administrador de inquilinos debe haber consentido anteriormente que todos los usuarios del inquilino usen la aplicación.
    • En otras palabras:
      • Usted como desarrollador ha hecho clic en el botón Conceder de Azure Portal.
      • O bien, un administrador de inquilinos ha hecho clic en el botón Conceder o revocar consentimiento del administrador para {dominio del inquilino} de la pestaña Permisos de API del registro de la aplicación. Para más información, consulte Adición de permisos para acceder a la API web.
      • O bien, ha proporcionado una manera para que los usuarios den su consentimiento a la aplicación. Para más información, consulte Solicitud de consentimiento de usuario individual.
      • O bien, ha proporcionado una forma para que el administrador de inquilinos otorgue su consentimiento a la aplicación. Para más información, consulte Consentimiento del administrador.
  • Este flujo está habilitado para aplicaciones de escritorio de .NET, .NET y UWP.

Para más información sobre el consentimiento, consulte Permisos y consentimiento de la Plataforma de identidad de Microsoft.

Aprenda a usarlo

En MSAL.NET, use:

AcquireTokenByIntegratedWindowsAuth(IEnumerable<string> scopes)

Normalmente solo necesita un parámetro (scopes). Según la forma en que el administrador de Windows configure las directivas, es posible que no se permita que las aplicaciones de la máquina Windows busquen al usuario que ha iniciado sesión. En ese caso, use un segundo método, .WithUsername(), y pase el nombre de usuario del usuario que ha iniciado sesión con un formato UPN, por ejemplo, joe@contoso.com.

El ejemplo siguiente presenta el caso más reciente, con explicaciones de la clase de excepciones que se pueden obtener y sus mitigaciones.

static async Task GetATokenForGraph()
{
 string authority = "https://login.microsoftonline.com/contoso.com";
 string[] scopes = new string[] { "user.read" };
 IPublicClientApplication app = PublicClientApplicationBuilder
      .Create(clientId)
      .WithAuthority(authority)
      .Build();

 var accounts = await app.GetAccountsAsync();

 AuthenticationResult result = null;
 if (accounts.Any())
 {
  result = await app.AcquireTokenSilent(scopes, accounts.FirstOrDefault())
      .ExecuteAsync();
 }
 else
 {
  try
  {
   result = await app.AcquireTokenByIntegratedWindowsAuth(scopes)
      .ExecuteAsync(CancellationToken.None);
  }
  catch (MsalUiRequiredException ex)
  {
   // MsalUiRequiredException: AADSTS65001: The user or administrator has not consented to use the application
   // with ID '{appId}' named '{appName}'.Send an interactive authorization request for this user and resource.

   // you need to get user consent first. This can be done, if you are not using .NET (which does not have any Web UI)
   // by doing (once only) an AcquireToken interactive.

   // If you are using .NET or don't want to do an AcquireTokenInteractive, you might want to suggest the user to navigate
   // to a URL to consent: https://login.microsoftonline.com/common/oauth2/v2.0/authorize?client_id={clientId}&response_type=code&scope=user.read

   // AADSTS50079: The user is required to use multi-factor authentication.
   // There is no mitigation - if MFA is configured for your tenant and AAD decides to enforce it,
   // you need to fallback to an interactive flows such as AcquireTokenInteractive or AcquireTokenByDeviceCode
   }
   catch (MsalServiceException ex)
   {
    // Kind of errors you could have (in ex.Message)

    // MsalServiceException: AADSTS90010: The grant type is not supported over the /common or /consumers endpoints. Please use the /organizations or tenant-specific endpoint.
    // you used common.
    // Mitigation: as explained in the message from Azure AD, the authority needs to be tenanted or otherwise organizations

    // MsalServiceException: AADSTS70002: The request body must contain the following parameter: 'client_secret or client_assertion'.
    // Explanation: this can happen if your application was not registered as a public client application in Azure AD
    // Mitigation: in the Azure portal, edit the manifest for your application and set the `allowPublicClient` to `true`
   }
   catch (MsalClientException ex)
   {
      // Error Code: unknown_user Message: Could not identify logged in user
      // Explanation: the library was unable to query the current Windows logged-in user or this user is not AD or AAD
      // joined (work-place joined users are not supported).

      // Mitigation 1: on UWP, check that the application has the following capabilities: Enterprise Authentication,
      // Private Networks (Client and Server), User Account Information

      // Mitigation 2: Implement your own logic to fetch the username (e.g. john@contoso.com) and use the
      // AcquireTokenByIntegratedWindowsAuth form that takes in the username

      // Error Code: integrated_windows_auth_not_supported_managed_user
      // Explanation: This method relies on a protocol exposed by Active Directory (AD). If a user was created in Azure
      // Active Directory without AD backing ("managed" user), this method will fail. Users created in AD and backed by
      // AAD ("federated" users) can benefit from this non-interactive method of authentication.
      // Mitigation: Use interactive authentication
   }
 }

 Console.WriteLine(result.Account.Username);
}

Para obtener la lista de posibles modificadores en AcquireTokenByIntegratedWindowsAuthentication, consulte AcquireTokenByIntegratedWindowsAuthParameterBuilder.

Pasos siguientes

Avance al siguiente artículo de este escenario, Llamada a una API web desde la aplicación de escritorio.