Поделиться через


Классическое приложение, вызывающее веб-API: получение токена с использованием встроенной проверки подлинности Windows

Чтобы войти в домен или присоединенный к нему компьютер Microsoft Entra, используйте интегрированные проверка подлинности Windows (IWA).

Ограничения

  • Интегрированная проверка подлинности Windows доступна только для федеративных пользователей, то есть пользователей, созданных в Active Directory и поддерживаемых идентификатором Microsoft Entra. Пользователи, созданные непосредственно в идентификаторе Microsoft Entra, без резервного копирования Active Directory, известного как управляемые пользователи, не могут использовать этот поток проверки подлинности. Это ограничение не влияет на поток имени пользователя и пароля.

  • IWA не обходит многофакторную проверку подлинности (MFA). Если настроена MFA, IWA может завершиться ошибкой, если требуется запрос MFA, так как для MFA требуется вмешательство пользователя.

    IWA не является интерактивным, но MFA требует взаимодействия с пользователем. Вы не контролируете, когда поставщик удостоверений запрашивает MFA. Это задача администратора клиента. По нашим наблюдениям, MFA требуется при входе из другой страны или региона, если вы не подключены через VPN к корпоративной сети, и иногда даже при подключении через VPN. Не следует рассчитывать на детерминированный набор правил. Идентификатор Microsoft Entra использует ИИ для непрерывного изучения необходимости MFA. Вернитесь к использованию запросов пользователя, например к интерактивной проверке подлинности или потоку кода устройства, при сбое IWA.

  • Центр, переданный PublicClientApplicationBuilder, должен иметь следующие характеристики:

    • Клиентский, вида https://login.microsoftonline.com/{tenant}/, где tenant — это идентификатор GUID, представляющий идентификатор клиента или домен, связанный с клиентом.
    • Для всех рабочих и учебных учетных записей: https://login.microsoftonline.com/organizations/.
    • Личные учетные записи Майкрософт не поддерживаются. Нельзя использовать клиенты /common или /consumers.
  • Встроенная проверка подлинности Windows является автоматическим потоком, поэтому:

    • Пользователь приложения должен быть предварительно одобрен, чтобы использовать приложение.
    • Администратор клиента должен предварительно одобрить всех пользователей в клиенте для использования приложения.
    • Другими словами:
      • Вы как разработчик выбрали Предоставить разрешения на портале Azure для себя.
      • Администратор клиента выбрал Предоставить или отозвать согласие администратора для {домен клиента} на вкладке Разрешения API в разделе регистрации приложения. Дополнительные сведения см. в разделе Добавление разрешений для доступа к веб-API.
      • Или вы предоставили пользователям возможность согласиться на приложение. Дополнительные сведения см. в разделе Запрос на получение согласия одного пользователя.
      • Или вы предоставили администратору клиента возможность согласиться на приложение. Дополнительные сведения см. в разделе Согласие администратора.
  • Этот поток включен для классических приложений .NET, .NET и UWP.

Дополнительные сведения о согласии см. в статье Разрешения и согласие платформы удостоверений Майкрософт.

Сведения об использовании

В MSAL.NET используйте:

AcquireTokenByIntegratedWindowsAuth(IEnumerable<string> scopes)

Обычно требуется только один параметр (scopes). В зависимости от способа настройки политик администратором Windows приложениям на компьютере Windows может быть запрещено выполнять поиск пользователя, выполнившего вход. В этом случае используйте второй метод, .WithUsername(), и передайте имя пользователя, выполнившего вход, в формате UPN, например joe@contoso.com.

В следующем примере представлен наиболее актуальный вариант с объяснениями типов исключений, которые могут возникать, и их устранения.

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);
}

Список возможных модификаторов AcquireTokenByIntegratedWindowsAuthentication см. в разделе AcquireTokenByIntegratedWindowsAuthParameterBuilder.

Следующие шаги

Перейдите к следующей статье в этом сценарии, Вызов веб-API из классического приложения.