Аутентификация и авторизация в Службе приложений

6 мин

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

Зачем использовать встроенную проверку подлинности?

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

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

служба приложение Azure позволяет интегрировать различные возможности проверки подлинности в веб-приложение или API, не реализуя их самостоятельно.
Аутентификация встроена непосредственно в платформу и не требует определенного языка, пакета SDK, опыта безопасности или кода.
Можно выполнить интеграцию с несколькими поставщиками входа. Например, идентификатор Microsoft Entra, Facebook, Google, X.

Поставщики удостоверений

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

Provider	Конечная точка входа	Практическое руководство
Microsoft Entra	`/.auth/login/aad`	входа платформы Microsoft Entra platform
Facebook	`/.auth/login/facebook`	Вход через Facebook в Службе приложений
Google	`/.auth/login/google`	Вход через Google в Службе приложений
X	`/.auth/login/x`	вход Служба приложений X
Любой поставщик OpenID Connect	`/.auth/login/<providerName>`	Вход через OpenID Connect в Службе приложений
GitHub	`/.auth/login/github`	вход Служба приложений GitHub

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

Принцип работы

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

ПО промежуточного слоя платформы обрабатывает несколько вещей для приложения:

Проверка подлинности пользователей и клиентов с помощью указанного поставщика удостоверений
Проверяет, хранит и обновляет маркеры OAuth, выданные настроенным поставщиком удостоверений
управление сеансом с проверкой подлинности;
вставка сведений об удостоверении в заголовки HTTP-запросов.

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

Примечание.

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

Поток аутентификации

Поток аутентификации одинаков для всех поставщиков, но будет различным для разных способов входа в систему: с использованием пакета SDK поставщика или без.

Без использования пакета SDK поставщика. Приложение делегирует федеративный вход в службу приложений. Обычно это относится к приложениям браузера, которые могут представлять пользователю страницу входа поставщика. Код сервера управляет процессом входа и называется потоком, направленным на сервер или потоком сервера.
С использованием пакета SDK поставщика. Вход пользователей в приложение на странице поставщика выполняется вручную, а затем приложение отправляет маркер проверки подлинности в Службу приложений Azure для проверки. Обычно это относится к внебраузерным приложениям, которые не могут предоставить пользователю страницу входа в систему. Код приложения управляет процессом входа и называется потоком , направленным клиентом или потоком клиента. Это относится к REST API, Функциям Azure, клиентам браузера на JavaScript и собственным мобильным приложениям, которые выполняют вход пользователей с помощью пакета SDK поставщика.

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

Этап	Без использования пакета SDK поставщика	С использованием пакета SDK поставщика
Вход пользователя	Перенаправляет клиента к `/.auth/login/<provider>`.	Код клиента выполняет вход пользователя непосредственно через пакет SDK поставщика и получает токен проверки подлинности. Дополнительные сведения см. в документации поставщика.
Действия после проверки подлинности	Поставщик перенаправляет клиент к `/.auth/login/<provider>/callback`.	Код клиента отправляет токен от поставщика к `/.auth/login/<provider>` для проверки.
Установка проверенного сеанса	Служба приложений добавляет файлы cookie, прошедшие проверку подлинности, в ответ.	Служба приложений возвращает собственный токен проверки подлинности в код клиента.
Обработка содержимого, прошедшего проверку подлинности	Клиент включает файлы cookie, прошедшие проверку подлинности, в последующие запросы (автоматически обрабатываются браузером).	Код клиента предоставляет токен проверки подлинности в заголовке `X-ZUMO-AUTH` (автоматически обрабатывается пакетами SDK для клиента мобильных приложений).

Для клиентских браузеров служба приложений может автоматически перенаправлять всех не прошедших проверку пользователей к /.auth/login/<provider>. Вы также можете отправить пользователям одну или несколько ссылок /.auth/login/<provider>, чтобы они вошли в ваше приложение с использованием поставщика по выбору.

Поведение авторизации

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

Разрешить неаутентифицированные запросы: этот вариант откладывает авторизацию трафика, не прошедшего аутентификацию, в код приложения. Для запросов, прошедших проверку подлинности, служба приложений также передает сведения о проверке подлинности в заголовках HTTP. Такой вариант обеспечивает большую гибкость в обработке анонимных запросов. Он позволяет предоставлять пользователям несколько поставщиков входа.
Требовать проверку подлинности: в этом варианте любой трафик к приложению, не прошедший проверку подлинности, отклоняется. Такое отклонение может заключаться в перенаправлении в один из настроенных поставщиков удостоверений. В таких случаях клиент браузера перенаправляется в /.auth/login/<provider> для выбранного поставщика. Если анонимный запрос поступает из собственного мобильного приложения, возвращаемый ответ HTTP 401 Unauthorized. Можно также настроить отклонение на возврат ответа HTTP 401 Unauthorized или HTTP 403 Forbidden для всех запросов.

Внимание

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

Хранилище токенов

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

Отладка и трассировка

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