Изменить

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

Проверка подлинности и авторизация Статические веб-приложения

  • Практическое руководство

Статические веб-приложения Azure обеспечивает упрощенную проверку подлинности, при которой дополнительная конфигурация не требуется для использования GitHub и идентификатора Microsoft Entra для проверки подлинности.

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

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

Предупреждение

Из-за изменений в политике API X (ранее Twitter) поддержка недоступна в рамках предварительно настроенных поставщиков для вашего приложения. Если вы хотите продолжать использовать X (ранее Twitter) для проверки подлинности и авторизации с приложением, обновите конфигурацию приложения, чтобы зарегистрировать настраиваемый поставщик.

Необходимые компоненты

Помните о следующих значениях по умолчанию и ресурсах для проверки подлинности и авторизации с помощью Статические веб-приложения Azure.

По умолчанию:

  • Любой пользователь может пройти проверку подлинности с помощью предварительно настроенного поставщика
    • GitHub
    • Microsoft Entra ID
    • Чтобы ограничить поставщик проверки подлинности, заблокируйте доступ с помощью настраиваемого правила маршрутизации.
  • После входа пользователи принадлежат к ролям и authenticated ролямanonymous. Дополнительные сведения о ролях см. в разделе "Управление ролями"

Ресурсы:

Настройка входа

Статические веб-приложения Azure используют системную папку /.auth для предоставления доступа к интерфейсам API, связанным с авторизацией. Вместо предоставления любого из маршрутов в папке /.auth непосредственно конечным пользователям создайте правила маршрутизации для понятных URL-адресов.

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

Поставщик авторизации Маршрут входа
Microsoft Entra ID /.auth/login/aad
GitHub /.auth/login/github

Например, для входа с помощью GitHub можно использовать URL-адрес, аналогичный следующему примеру.

<a href="/.auth/login/github">Login</a>

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

{
  "route": "/login",
  "redirect": "/.auth/login/github"
}

Настройка перенаправления после входа

Пользователь может вернуться на определенную страницу после входа, указав полный URL-адрес в параметре post_login_redirect_uri строки запроса.

<a href="/.auth/login/github?post_login_redirect_uri=https://zealous-water.azurestaticapps.net/success">Login</a>

You can also redirect unauthenticated users back to the referring page after they sign in. To add this redirect, create a response override rule that sets post_login_redirect_uri to .referrer, like in the following example.

{
  "responseOverrides": {
    "401": {
      "redirect": "/.auth/login/github?post_login_redirect_uri=.referrer",
      "statusCode": 302
    }
  }
}

Настройка выхода

Маршрут /.auth/logout выходит из веб-сайта. Вы можете добавить ссылку на навигацию по сайту, чтобы разрешить пользователю выйти, как показано в следующем примере.

<a href="/.auth/logout">Log out</a>

Используйте правило маршрута для сопоставления понятного маршрута, например /logout.

{
  "route": "/logout",
  "redirect": "/.auth/logout"
}

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

Чтобы вернуть пользователя на определенную страницу после выхода, укажите URL-адрес в post_logout_redirect_uri параметре строки запроса.

Блокировка поставщика проверки подлинности

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

Чтобы заблокировать поставщика, создайте правило маршрута для возврата 404 кода состояния для запросов к заблокированным маршруту для конкретного поставщика. Например, чтобы ограничить идентификатор entra (ранее Azure Active Directory, известный как "aad"), добавьте следующее правило маршрута.

{
  "route": "/.auth/login/aad",
  "statusCode": 404
}

Удаление персональных данных

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

Конечным пользователям необходимо обратиться к администраторам отдельных веб-приложений, чтобы удалить эти сведения в системах.

Чтобы удалить персональные данные из платформы Статические веб-приложения Azure и запретить платформе предоставлять эти сведения о будущих запросах, отправьте запрос с помощью следующего URL-адреса:

https://identity.azurestaticapps.net/.auth/purge/<AUTHENTICATION_PROVIDER_NAME>

To prevent the platform from providing this information on future requests to individual apps, submit a request using the following URL:

https://<WEB_APP_DOMAIN_NAME>/.auth/purge/<AUTHENTICATION_PROVIDER_NAME>

If you're using Microsoft Entra ID, use aad as the value for the <AUTHENTICATION_PROVIDER_NAME> placeholder.

Tip

For information about general restrictions and limitations, see Quotas.

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

Использование маршрутов для задания разрешенных ролей для управления доступом к страницам