Partilhar via


Aplicativo de área de trabalho que chama APIs da Web: adquira um token usando a autenticação integrada do Windows

Para entrar em um usuário de domínio em um domínio ou máquina associada ao Microsoft Entra, use a autenticação integrada do Windows (IWA).

Restrições

  • A autenticação integrada do Windows está disponível apenas para usuários federated+ , ou seja, usuários criados no Ative Directory e apoiados pelo Microsoft Entra ID. Os usuários criados diretamente no Microsoft Entra ID sem o suporte do Ative Directory, conhecidos como usuários gerenciados , não podem usar esse fluxo de autenticação. Essa limitação não afeta o fluxo de nome de usuário e senha.

  • A IWA não ignora a autenticação multifator (MFA). Se a MFA estiver configurada, a IWA poderá falhar se for necessário um desafio de MFA, porque a MFA requer interação do usuário.

    A IWA não é interativa, mas a MFA requer interatividade do usuário. Você não controla quando o provedor de identidade solicita que a MFA seja executada, o administrador do locatário faz. De acordo com nossas observações, a MFA é necessária quando você entra de um país/região diferente, quando não está conectado via VPN a uma rede corporativa e, às vezes, até mesmo quando conectado via VPN. Não espere um conjunto determinista de regras. O Microsoft Entra ID usa IA para saber continuamente se o MFA é necessário. Volte para um prompt do usuário, como autenticação interativa ou fluxo de código do dispositivo, se a IWA falhar.

  • A autoridade aprovada PublicClientApplicationBuilder tem de ser:

    • Locatário do formulário https://login.microsoftonline.com/{tenant}/, onde tenant é o GUID que representa o ID do locatário ou um domínio associado ao locatário.
    • Para todas as contas de trabalho e de escola: https://login.microsoftonline.com/organizations/.
    • As contas pessoais da Microsoft não são suportadas. Não é possível usar locatários /common ou /consumers.
  • Como a autenticação integrada do Windows é um fluxo silencioso:

    • O utilizador da sua aplicação deve ter consentido previamente a utilização da aplicação.
    • Ou, o administrador do locatário deve ter consentido previamente que todos os usuários do locatário usem o aplicativo.
    • Por outras palavras:
      • Você, como desenvolvedor, selecionou o botão Conceder no portal do Azure para si mesmo.
      • Ou, um administrador de locatário selecionou o botão Conceder/revogar consentimento de administrador para {domínio do locatário} na guia Permissões da API do registro para o aplicativo. Para obter mais informações, consulte Adicionar permissões para acessar sua API da Web.
      • Ou, você forneceu uma maneira para os usuários consentirem com o aplicativo. Para obter mais informações, consulte Solicitando consentimento de usuário individual.
      • Ou, você forneceu uma maneira para o administrador do locatário consentir com o aplicativo. Para obter mais informações, consulte Consentimento do administrador.
  • Esse fluxo está habilitado para aplicativos de área de trabalho .NET, .NET e UWP.

Para obter mais informações sobre consentimento, consulte Permissões e consentimento da plataforma de identidade da Microsoft.

Saiba como usá-lo

Em MSAL.NET, utilize:

AcquireTokenByIntegratedWindowsAuth(IEnumerable<string> scopes)

Normalmente, você precisa de apenas um parâmetro (scopes). Dependendo da forma como o administrador do Windows configurou as políticas, as aplicações na sua máquina Windows poderão não ter permissão para procurar o utilizador com sessão iniciada. Nesse caso, .WithUsername()use um segundo método e passe o nome de usuário do usuário conectado como um formato UPN, por exemplo, joe@contoso.com.

O exemplo a seguir apresenta o caso mais atual, com explicações sobre o tipo de exceções que você pode obter e suas atenuações.

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 obter a lista de possíveis modificadores em AcquireTokenByIntegratedWindowsAuthentication, consulte AcquireTokenByIntegratedWindowsAuthParameterBuilder.

Próximos passos

Passe para o próximo artigo neste cenário, Chamar uma API da Web a partir do aplicativo da área de trabalho.