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

Настройте своё приложение App Service или Azure Functions для использования входа в систему Microsoft Entra.

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

В этой статье рассказывается, как настроить аутентификацию для Azure App Service или Azure Functions, чтобы ваше приложение входило в учетные записи пользователей, используя платформу идентификации Microsoft (Microsoft Entra) в качестве поставщика аутентификации.

Выберите арендатора для вашего приложения и его пользователей.

Прежде чем ваше приложение сможет входить в систему пользователей, вам необходимо зарегистрировать его в рабочем или внешнем арендаторе. Если вы предоставляете доступ к своему приложению сотрудникам или бизнес-гостям, зарегистрируйте свое приложение в рабочем клиенте. Если ваше приложение предназначено для потребителей и бизнес-клиентов, зарегистрируйте его в внешнем клиенте.

  1. Войдите на портал Azure и перейдите в приложение.

  2. В меню слева в вашем приложении выберите Настройки>Аутентификация, а затем выберите Добавить провайдера идентификации.

  3. На странице "Добавление поставщика удостоверений" выберите Microsoft в качестве значения поставщика удостоверений для входа с помощью удостоверений Microsoft и Microsoft Entra.

  4. В разделе "Выбор клиента для приложения и его пользователей" выберите один из следующих вариантов:

    • Конфигурация рабочей силы (текущий клиент) для сотрудников и бизнес-гостей
    • Внешняя конфигурация для потребителей и корпоративных клиентов

Выберите регистрацию приложения

Функция аутентификации службы приложений может автоматически создать регистрацию приложения для вас. Или вы можете использовать регистрацию, которую вы или администратор каталога создаете отдельно.

Автоматически создайте регистрацию приложения, если только вам не нужно создать регистрацию приложения отдельно. Вы можете настроить регистрацию приложения в Центре администрирования Microsoft Entra позже, если вы хотите.

Ниже приведены наиболее распространенные случаи использования существующей регистрации приложения:

  • У вашей учетной записи нет разрешений на создание регистраций приложений в клиенте Microsoft Entra.
  • Вы хотите использовать регистрацию приложения из другого клиента Microsoft Entra, а не из того, который содержит ваше приложение. Это всегда происходит, если вы выбрали Внешняя конфигурация при выборе арендатора.
  • Вариант создания новой регистрации недоступен для правительственных облаков.

Вариант 1: Создать и использовать новую регистрацию приложения

  1. Выберите "Создать регистрацию приложения".

  2. В поле "Имя" введите имя регистрации нового приложения.

  3. Выберите значение Supported account type.

    • Текущий арендатоплательщик - Единственный арендатор. Учетные записи только в этом организационном каталоге. Все учетные записи пользователей и гостевых учетных записей в каталоге могут использовать приложение или API. Используйте этот параметр, если целевая аудитория является внутренней для вашей организации.
    • Любой каталог Microsoft Entra — многопользовательский. Учетные записи в любом организационном каталоге. Все пользователи с рабочей или учебной учетной записью Microsoft могут использовать ваше приложение или API. Эти учетные записи включают школы и предприятия, которые используют Office 365. Используйте этот параметр, если ваша целевая аудитория — бизнес-клиенты или образовательные учреждения, и чтобы включить многопользовательский режим.
    • Любой каталог Microsoft Entra и личные учетные записи Microsoft. Учетные записи в любом каталоге организации и личных учетных записях Майкрософт (например, Skype или Xbox). Все пользователи с рабочей или учебной учетной записью, или персональной учетной записью Microsoft, могут использовать ваше приложение или API. Она включает школы и предприятия, которые используют Office 365, а также личные аккаунты, которые используются для входа в службы, такие как Xbox и Skype. Используйте этот параметр, чтобы охватить наибольшее количество учетных записей Microsoft и включить многопользовательский режим.
    • Только личные аккаунты Microsoft. Личные учетные записи, которые используются для входа в такие сервисы, как Xbox и Skype. Используйте эту опцию, чтобы нацелиться на самый широкий набор идентификаторов Microsoft.

При желании вы можете позже изменить имя регистрации или типы поддерживаемых учетных записей.

Клиентский секрет создается как привязка к слоту в настройках приложения с именем MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Если вы хотите управлять секретом в Azure Key Vault, вы можете позже обновить этот параметр, чтобы использовать ссылки на Key Vault. В качестве альтернативы, вы можете изменить это на использование идентификатора вместо клиентского секрета. Поддержка использования идентификации в настоящее время находится в стадии предварительного просмотра.

Вариант 2: Используйте уже существующую регистрацию, созданную отдельно

Чтобы использовать существующую регистрацию, выберите один из следующих вариантов:

  • Выберите существующую регистрацию приложения в этом каталоге. Затем выберите регистрацию приложения из выпадающего списка.

  • Предоставьте подробности существующей регистрации приложения. Затем предоставьте:

    • Идентификатор приложения (клиента).

    • Секрет клиента (рекомендуется). Секретное значение, которое приложение использует для подтверждения своей идентичности при запросе токена. Это значение сохраняется в конфигурации вашего приложения как настройка приложения с фиксированным слотом, названная MICROSOFT_PROVIDER_AUTHENTICATION_SECRET. Если секрет клиента не установлен, операции входа в систему из сервиса используют поток OAuth 2.0 с неявным предоставлением, который мы не рекомендуем.

      Вы также можете настроить приложение для использования удостоверения вместо секрета клиента. Поддержка использования идентификации в настоящее время находится в стадии предварительного просмотра.

    • URL-адрес издателя. Этот URL-адрес принимает форму <authentication-endpoint>/<tenant-id>/v2.0. Замените <authentication-endpoint> на значение конечной точки аутентификации, которое специфично для облачной среды. Например, клиент рабочей нагрузки в глобальном Azure использует https://sts.windows.net как свою конечную точку аутентификации.

Если вам нужно вручную создать регистрацию приложения в арендаторе рабочей силы, см. Регистрация приложения на платформе идентификации Microsoft. В процессе регистрации обязательно запишите значения идентификатора приложения (клиента) и клиентского секрета.

Во время регистрации в разделе URI перенаправления выберите Веб-сайт для платформы и введите URI перенаправления. Например, введите https://contoso.azurewebsites.net/.auth/login/aad/callback.

Теперь измените регистрацию приложения:

  1. На левой панели выберите Предоставить доступ к API>, затем Добавить>, и Сохранить. Это значение уникально идентифицирует приложение, когда оно используется как ресурс, что позволяет запрашивать токены, предоставляющие доступ. Значение является префиксом для областей, которые вы создаете.

    Для одноарендного приложения вы можете использовать значение по умолчанию, которое имеет форму api://<application-client-id>. Вы также можете указать более удобочитаемый универсальный идентификатор ресурса (URI https://contoso.com/api), основанный на одном из проверенных доменов вашего арендатора. Для многопользовательского приложения необходимо предоставить пользовательский URI. Для получения дополнительной информации о допустимых форматах для URI идентификаторов приложения, см. Рекомендуемые меры безопасности для свойств приложения в Microsoft Entra ID.

  2. Выберите Добавить область, а затем:

    1. В поле "Имя области" введите user_impersonation.
    2. В разделе Кто может дать согласие выберите Администраторы и пользователи, если вы хотите разрешить пользователям давать согласие на эту область.
    3. Введите имя области согласия. Введите описание, которое вы хотите, чтобы пользователи увидели на странице согласия. Например, введите имя приложенияAccess.
    4. Выберите Добавить область.

  3. (Рекомендуется) Создайте утверждение клиента для приложения. Чтобы создать клиентский секрет:

    1. В левой панели выберите Сертификаты и секреты>Секреты клиента>Новый секрет клиента.
    2. Введите описание и срок действия, затем выберите Добавить.
    3. Скопируйте значение секрета клиента в поле "Значение ". После перехода с этой страницы он снова не отображается.

    Вы также можете настроить приложение для использования удостоверения вместо секрета клиента. Поддержка использования идентификации в настоящее время находится в стадии предварительного просмотра.

  4. (Необязательно) Чтобы добавить несколько URL-ответов, выберите Аутентификация.

Настройте дополнительные проверки

Дополнительные проверки определяют, какие запросы разрешены для доступа к приложению. Вы можете настроить это поведение сейчас или настроить эти параметры позже на главной странице проверки подлинности , нажав кнопку "Изменить рядом с параметрами проверки подлинности".

Для требования клиентского приложения выберите, следует ли:

  • Разрешить запросы только от этого приложения.
  • Разрешить запросы от определённых клиентских приложений.
  • Разрешить запросы от любого приложения (не рекомендуется).

Для Требования к идентификации выберите, что делать:

  • Разрешить запросы от любой личности.
  • Разрешить запросы от определенных пользователей.

Для Требования арендатора выберите, следует ли:

  • Разрешать запросы только от арендатора-эмитента.
  • Разрешить запросы от определенных клиентов.
  • Используйте ограничения по умолчанию на основе эмитента.

Вашему приложению все еще может понадобиться принимать другие решения об авторизации в коде. Для получения дополнительной информации см. Использование встроенной политики авторизации далее в этой статье.

Настроить параметры аутентификации

Настройки аутентификации определяют, как ваше приложение реагирует на запросы без аутентификации. Все запросы по умолчанию будут перенаправлены для входа через этого нового поставщика. Вы можете настроить это поведение сейчас или настроить эти параметры позже на главной странице проверки подлинности , нажав кнопку "Изменить рядом с параметрами проверки подлинности". Для получения дополнительной информации см. процесс аутентификации.

Для Ограничить доступ, решите, следует ли:

  • Требуется аутентификация.
  • Разрешить неаутентифицированный доступ.

Для неаутентифицированные запросы выберите параметры ошибок.

  • HTTP 302 Found redirect: рекомендуется для сайтов
  • HTTP 401 Unauthorized: рекомендовано для API
  • HTTP 403 Forbidden
  • HTTP 404 Not found

Выберите Хранилище токенов (рекомендуется). Хранилище токенов собирает, хранит и обновляет токены для вашего приложения. Это поведение можно отключить позже, если приложению не нужны маркеры или вам нужно оптимизировать производительность.

Добавьте поставщика удостоверений

Если выбрана конфигурация рабочей силы, вы можете выбрать "Далее": "Разрешения " и добавить все разрешения Microsoft Graph, необходимые приложению. Эти разрешения добавляются в регистрацию приложения, но их можно изменить позже. Если вы выбрали внешнюю конфигурацию, вы можете добавить разрешения Microsoft Graph позже.

  • Нажмите кнопку "Добавить".

Теперь вы готовы использовать платформу удостоверений Майкрософт для проверки подлинности в приложении. Провайдер указан на странице Аутентификация. Отсюда вы можете редактировать или удалить эту конфигурацию провайдера.

Чтобы ознакомиться с примером настройки входа Microsoft Entra для веб-приложения, которое обращается к Azure Storage и Microsoft Graph, см. Добавить аутентификацию приложения в ваше веб-приложение.

Авторизовать запросы

По умолчанию аутентификация в службе приложений обрабатывает только аутентификацию. Он определяет, является ли вызывающий лицом, за которого себя выдает. Авторизация, это определение того, должен ли вызывающий абонент иметь доступ к некоторому ресурсу, является шагом, который выходит за рамки аутентификации. Для получения дополнительной информации смотрите Основы авторизации.

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

Подсказка

Приложения с поддержкой нескольких арендаторов должны проверять издателя и идентификатор арендатора запроса в рамках этого процесса, чтобы убедиться, что эти значения разрешены. Когда аутентификация службы приложений настроена для многосрочного сценария, она не проверяет, от какого арендатора поступает запрос. Приложение, возможно, потребуется ограничить для определённых арендаторов, в зависимости от того, подписалась ли организация на услугу (например). См. Обновите свой код для обработки нескольких значений эмитента.

Выполняйте проверки из кода приложения

Когда вы выполняете проверки авторизации в коде своего приложения, вы можете использовать информацию об утверждениях, которую предоставляет аутентификация App Service. Для получения дополнительной информации см. Доступ к пользовательским требованиям в коде приложения.

Внедренный заголовок x-ms-client-principal содержит объект JSON с кодировкой Base64, содержащий утверждения о вызывающем абоненте. По умолчанию эти утверждения проходят сопоставление утверждений, поэтому имена утверждений могут не всегда совпадать с теми, которые вы увидите в токене. Например, требование tid вместо этого сопоставлено с http://schemas.microsoft.com/identity/claims/tenantid.

Вы также можете работать непосредственно с основным токеном доступа из внедренного заголовка x-ms-token-aad-access-token.

Используйте встроенную политику авторизации

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

Код вашего приложения часто является лучшим местом для обработки пользовательской логики авторизации. Однако для распространённых сценариев платформа идентификации Microsoft предоставляет встроенные проверки, которые вы можете использовать для ограничения доступа.

Этот раздел показывает, как включить встроенные проверки с помощью API аутентификации App Service V2. В настоящее время единственный способ настроить эти встроенные проверки — использовать шаблоны Azure Resource Manager или REST API.

В объекте API конфигурация поставщика идентификационных данных Microsoft Entra содержит раздел validation, который может включать объект defaultAuthorizationPolicy, как показано в следующей структуре:

{
    "validation": {
        "defaultAuthorizationPolicy": {
            "allowedApplications": [],
            "allowedPrincipals": {
                "identities": []
            }
        }
    }
}
Собственность Описание
defaultAuthorizationPolicy Группа требований, которые должны быть выполнены для доступа к приложению. Доступ предоставляется на основе логического AND, примененного ко всем его настроенным свойствам. Когда и allowedApplications, и allowedPrincipals настроены, входящий запрос должен удовлетворять обоим требованиям, чтобы быть принятым.
allowedApplications Разрешенный список строковых идентификаторов клиентских ID, представляющих ресурс клиента, который обращается к приложению. Когда это свойство настроено как непустой массив, принимаются только токены, полученные приложением, указанным в списке.

Эта политика оценивает требование appid или azp входящего токена, который должен быть токеном доступа. См. Payload claims.
allowedPrincipals Группа проверок, определяющих, может ли субъект, который представляет входящий запрос, получить доступ к приложению. Удовлетворение allowedPrincipals основано на логическом OR, применяемом к его настроенным свойствам.
identities (под allowedPrincipals) Разрешающий список строковых идентификаторов объектов, которые представляют пользователей или приложения, имеющие доступ. Когда это свойство настроено как непустой массив, требование allowedPrincipals может быть выполнено, если пользователь или приложение, которое представляет запрос, указаны в списке. Существует ограничение в 500 символов (всего) для всего списка идентификаторов.

Эта политика оценивает претензию входящего токена oid. См. Payload claims.

Вы также можете настроить некоторые проверки через application setting, независимо от версии API, которую вы используете. Вы можете настроить параметр приложения WEBSITE_AUTH_AAD_ALLOWED_TENANTS, указав список идентификаторов арендаторов через запятую, содержащий до 10 значений; например, aaaabbbb-0000-cccc-1111-dddd2222eeee. Эта настройка может требовать, чтобы входящий токен исходил от одного из указанных арендаторов, как указано в претензии tid.

Чтобы требовать, чтобы входящие маркеры включали утверждение WEBSITE_AUTH_AAD_REQUIRE_CLIENT_SERVICE_PRINCIPAL, можно настроить параметр приложения true на 1 или oid. Если вы настроили allowedPrincipals.identities, этот параметр игнорируется и считается истинным, потому что утверждение oid проверяется относительно предоставленного списка идентификаторов.

Запросы, которые не проходят эти встроенные проверки, получают ответ HTTP 403 Forbidden.

Используйте управляемую идентичность вместо секрета (предварительная версия)

Вместо настройки секретного ключа клиента для вашей регистрации приложения, вы можете настроить приложение на доверие управляемой идентичности (предварительный просмотр). Использование удостоверения вместо секрета означает, что вам не нужно управлять секретом. У вас нет событий истечения срока действия секрета, чтобы с ними разбираться, и у вас нет такого же уровня риска, связанного с возможным раскрытием или утечкой этого секрета.

Идентификатор позволяет создать учетные данные федеративной идентификации, которые могут использоваться вместо клиентского секрета в качестве утверждения клиента. Этот подход доступен только для конфигураций трудовых ресурсов. Встроенная функция аутентификации в настоящее время поддерживает учетные данные федеративной идентификации в качестве предварительного просмотра.

Действия, описанные в этом разделе, можно использовать для настройки ресурса Службы приложений или Функций Azure для использования этого шаблона. Предполагается, что на данном этапе вы уже зарегистрировали приложение, используя один из поддерживаемых методов, и у вас уже определён секрет.

  1. Создайте ресурс управляемой идентичности, назначенный пользователем, в соответствии с этими инструкциями.

  2. Назначьте этот идентификатор вашему ресурсу App Service или Azure Functions.

    Это важно

    Созданная вами управляемая идентичность пользователя должна назначаться только для приложения App Service или Azure Functions через эту регистрацию. Если вы назначаете идентификатор другому ресурсу, вы тем самым предоставляете этому ресурсу ненужный доступ к регистрации вашего приложения.

  3. Запишите значения Object ID и Client ID управляемого удостоверения. Вам потребуется идентификатор объекта, чтобы создать удостоверение федеративной идентичности на следующем этапе. Вы будете использовать идентификатор клиента управляемой идентичности на следующем этапе.

  4. Следуйте инструкциям Microsoft Entra ID для настройки учетных данных федеративной идентификации в существующем приложении. Эти инструкции также включают разделы по обновлению кода приложения, которые вы можете пропустить.

  5. Добавьте новую настройку приложения с именем OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Установите его значение в значение ID клиента управляемой идентичности, которое вы получили на предыдущем этапе. Не используйте идентификатор клиента вашей регистрации приложения. Убедитесь, что эта настройка приложения отмечена как привязка к слоту.

  6. В параметрах встроенной аутентификации для ресурса вашего приложения установите имя параметра секрета клиента на OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

    Для внесения этих изменений с использованием портала Azure:

    1. Вернитесь к ресурсу App Service или Azure Functions и выберите вкладку Аутентификация.
    2. В разделе Поставщик удостоверений для записи Microsoft выберите значок в колонке Редактировать.
    3. В диалоговом окне Редактировать поставщика удостоверений откройте раскрывающийся список для Имя настройки клиентского секрета и выберите OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.
    4. Выберите Сохранить.

    Чтобы внести это изменение с помощью REST API:

    • Задайте для свойства clientSecretSettingName значение OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID. Вы можете найти этот параметр под properties>identityProviders>azureActiveDirectory>registration.

  7. Проверьте, работает ли приложение так, как вы ожидаете. Вы сможете успешно выполнить новое действие входа.

Когда вы будете удовлетворены поведением с использованием управляемой идентификации, удалите существующий секрет.

  1. Убедитесь, что код приложения не зависит от параметра приложения. Если это так, следуйте инструкциям по обновлению кода приложения для запроса токена доступа.

  2. Удалите параметр приложения, который ранее содержал ваш секрет. Имя этого параметра приложения — это предыдущее значение секрета клиента, прежде чем задать его в OVERRIDE_USE_MI_FIC_ASSERTION_CLIENTID.

  3. Войдите в Административный центр Microsoft Entra, используя арендатора, который содержит регистрацию вашего приложения. Перейдите к регистрации приложения снова.

  4. В разделе Сертификаты и секреты выберите Секреты клиента и удалите секрет клиента.

Теперь приложение настроено на использование проверки подлинности идентификатора Microsoft Entra без секретов.

Настройка клиентских приложений для доступа к Службе приложений

В предыдущих разделах вы зарегистрировали своё приложение App Service или Azure Functions для аутентификации пользователей. Следующие разделы объясняют, как зарегистрировать нативные клиенты или демон-приложения в Microsoft Entra. Эти клиенты или приложения могут запрашивать доступ к API, предоставляемым службой App Service, от имени пользователей или от своего имени, как, например, в многослойной архитектуре. Если вы хотите только аутентифицировать пользователей, шаги в следующих разделах не требуются.

Нативное клиентское приложение

Вы можете зарегистрировать локальных клиентов для запроса доступа к API вашего приложения App Service от имени вошедшего в систему пользователя.

  1. В меню портала Azure выберите Microsoft Entra ID.

  2. В левой панели выберите Управление>Регистрация приложений. Затем выберите New registration.

  3. На панели Регистрация приложения для Имя введите имя для регистрации вашего приложения.

  4. В URI перенаправления выберите публичный клиент / собственный (мобильный и настольный) и введите URL-адрес перенаправления. Например, введите https://contoso.azurewebsites.net/.auth/login/aad/callback.

  5. Выберите Зарегистрировать.

  6. После создания регистрации приложения скопируйте значение ID приложения (клиента).

    Заметка

    Для приложения Microsoft Store вместо этого используйте идентификатор SID пакета в качестве URI.

  7. На левой панели выберите "Управление разрешениями>API". Затем нажмите кнопку "Добавить разрешение>" Мои API".

  8. Выберите регистрацию приложения, которую вы создали ранее для вашего приложения App Service. Если вы не видите регистрацию приложения, убедитесь, что добавили область user_impersonation в регистрацию приложения.

  9. В разделе Делегированные разрешения выберите user_impersonation, и затем выберите Добавить разрешения.

Теперь вы настроили клиентское приложение, которое может запрашивать доступ к вашему приложению App Service от имени пользователя.

Демон клиентское приложение (вызовы между сервисами)

В N-уровневой архитектуре ваше клиентское приложение может получить токен для вызова приложения App Service или Azure Functions от имени самого клиентского приложения, а не от имени пользователя. Этот сценарий полезен для неинтерактивных приложений-демонов, которые выполняют задачи без входа пользователя. Он использует стандартное предоставление учетных данных клиента OAuth 2.0. Для получения дополнительной информации см. Microsoft identity platform and the OAuth 2.0 client credentials flow.

  1. В меню портала Azure выберите Microsoft Entra ID.

  2. В левой панели выберите Управление>Регистрация приложений. Затем выберите New registration.

  3. На панели Регистрация приложения для Имя введите имя для регистрации вашего приложения.

  4. Для демон-приложения вам не нужно указывать URI перенаправления, поэтому вы можете оставить поле Redirect URI пустым.

  5. Выберите Зарегистрировать.

  6. После создания регистрации приложения скопируйте значение ID приложения (клиента).

  7. На левой панели выберите "Управление>сертификатами и секретами". Затем выберите секреты клиента>новый секрет клиента.

  8. Введите описание и срок действия, затем выберите Добавить.

  9. Скопируйте значение секрета клиента в поле "Значение ". После перехода с этой страницы он снова не отображается.

Теперь вы можете запросить токен доступа, используя идентификатор клиента и секретный ключ клиента. Установите parameter resource на значение Application ID URI целевого приложения. Затем полученный токен доступа можно предоставить целевому приложению через стандартный заголовок авторизации OAuth 2.0. Аутентификация службы приложений проверяет и использует токен для указания, что вызывающий объект аутентифицирован. В этом случае вызывающим является приложение, а не пользователь.

Этот подход позволяет любому клиентскому приложению в вашем Microsoft Entra тенанте запросить токен доступа и пройти аутентификацию для целевого приложения. Если вы также хотите применить авторизацию, чтобы разрешить только определенные клиентские приложения, необходимо выполнить дополнительную настройку.

  1. Определите роль приложения в манифесте регистрации приложения, представляющего приложение Службы приложений или приложение Функций Azure, которое требуется защитить.

  2. В регистрации приложения, представляющего клиента, который нуждается в авторизации, выберите Разрешения API>Добавить разрешение>Мои API.

  3. Выберите регистрацию приложения, которую вы создали ранее. Если вы не видите регистрацию приложения, убедитесь, что вы добавили роль приложения.

  4. В разделе Разрешения приложения выберите роль приложения, которую вы создали ранее. Затем выберите Добавить разрешения.

  5. Выберите "Предоставить согласие администратора", чтобы авторизовать клиентское приложение, чтобы запросить разрешение.

    Аналогично предыдущему сценарию (прежде чем добавлять все роли), теперь можно запросить маркер доступа для того же целевого ресурса. Токен доступа включает утверждение roles, которое содержит роли приложения, авторизованные для клиентского приложения.

В коде целевого приложения App Service или Azure Functions теперь можно проверить, что токен содержит ожидаемые роли. Аутентификация App Service не выполняет эту проверку. Для получения дополнительной информации см. Доступ к пользовательским требованиям в коде приложения.

Теперь вы настроили клиентское приложение-демон, которое может получить доступ к вашему приложению App Service, используя свою собственную идентичность.

Лучшие практики

Независимо от конфигурации, которую вы используете для настройки аутентификации, следующие лучшие практики помогут сделать вашего арендатора и приложения более защищенными.

  • Настройте каждое приложение службы App Service с собственной регистрацией приложения в Microsoft Entra.
  • Дайте каждому приложению службы App Service собственные разрешения и согласие.
  • Избегайте совместного использования разрешений между средами. Используйте отдельные регистрации приложений для отдельных слотов развертывания. При тестировании нового кода эта практика может помочь предотвратить проблемы, влияющие на рабочее приложение.

Перейдите на Microsoft Graph

Некоторые старые приложения могут быть настроены с зависимостью от Azure AD Graph, который устарел и планируется полностью снять с эксплуатации. Например, код вашего приложения может обращаться к Azure AD Graph для проверки членства в группе в качестве части фильтра авторизации в промежуточном программном потоке. Приложения следует перенести на Microsoft Graph. Для получения дополнительной информации см. раздел Migrate your apps from Azure AD Graph to Microsoft Graph.

Во время этой миграции вам, возможно, потребуется внести некоторые изменения в конфигурацию аутентификации App Service. После добавления разрешений Microsoft Graph в регистрацию вашего приложения, вы сможете:

  • Обновите значение URL-адреса издателя чтобы добавить суффикс /v2.0, если он еще не добавлен.

  • Удалите запросы на разрешения Azure AD Graph из вашей конфигурации входа. Свойства для изменения зависят от той версии API управления, которую вы используете:

    • Если вы используете API версии 1 (/authsettings), этот параметр находится в массиве additionalLoginParams.
    • Если вы используете API V2 (/authsettingsV2), эта настройка находится в массиве loginParameters.

    Вам необходимо удалить любые упоминания о https://graph.windows.net, например. Это изменение включает параметр resource, который не поддерживается конечной точкой /v2.0. Она также включает любые области, которые вы специально запрашиваете и которые происходят из Azure AD Graph.

    Вам также необходимо обновить конфигурацию, чтобы запросить новые разрешения Microsoft Graph, которые вы настроили для регистрации приложения. Во многих случаях вы можете использовать default scope, чтобы упростить эту настройку. Чтобы это сделать, добавьте новый параметр входа: scope=openid profile email https://graph.microsoft.com/.default.

С этими изменениями аутентификация службы приложений больше не запрашивает разрешения на доступ к Azure AD Graph при попытке входа. Вместо этого он получает токен для Microsoft Graph. Любое использование этого токена в вашем коде приложения также должно быть обновлено, как описано в Миграция ваших приложений с Azure AD Graph на Microsoft Graph.

Связанная информация