Пошаговое руководство с примером проекта

При развертывании веб-приложений или API-интерфейсов в Функциях Azure вы можете либо предоставлять их напрямую из конечной точки функции Azure, либо обслуживать их через Azure APIM. Использование APIM имеет несколько преимуществ, таких как маршрутизация к различным приложениям на основе пути контекста, реализация микросервисов, добавление OAuth, уровень кэширования, совместное использование ваших API через портал разработчика и т. Д.

В этом посте мы увидим, как настроить OAuth 2.0 для API-интерфейсов Java, работающих в Функциях Azure, через Azure APIM.

  • Предварительные требования
  • Пример проекта
  • Запуск API в Функциях Azure
  • Запуск API в функциях Azure через APIM
  • Создание регистраций приложений
  • Настройка OAuth 2.0
  • Добавление OAuth 2.0 в API Gateway
  • Добавление политик для проверки токена
  • Тестирование с Postman
  • Резюме
  • Заключение

Предпосылки

Если вы хотите написать бессерверный NodeJS REST API, вам нужно знать множество вещей. Во-первых, вам нужно создать две учетные записи: учетную запись Github для хранения исходного кода и учетную запись Microsoft для развертывания этого кода с помощью службы приложений-функций. Давайте создадим эти учетные записи, перейдя по ссылкам ниже. И то, и другое можно запустить бесплатно.

Поскольку мы создаем приложение Java REST API, вам необходимо быть знакомым с java и инструментом Maven. Вам необходимо установить Java SDK на локальный компьютер.

Весь код API написан на функциях Java Azure. Вам необходимо знать следующее.

Если вы новичок в Azure, ознакомьтесь со статьей ниже, чтобы узнать, как начать работу.

Учетная запись Microsoft Azure

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

Вам необходимо создать подписку для своей учетной записи. Самая распространенная - подписка Pay As You Go.

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

Пример проекта

Это простой Java REST API, в котором вы можете добавлять задачи, удалять задачи, обновлять задачи и получать задачи. Вот пример проекта, который вы можете клонировать и запустить на своем локальном компьютере.

// clone the project
git clone https://github.com/bbachi/serverless-java-restapi-azure.git

Запуск API в Функциях Azure

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

Как написать бессерверный Java REST API с помощью функций Azure

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

Вы можете щелкнуть URL-адрес и нажать GET-запрос, как показано ниже, и вы получите результат, как показано ниже.

https://funcjavaapi.azurewebsites.net/api/todo-get

Запуск API в функциях Azure через APIM

Вот подробная статья о развертывании NodeJS REST API в Функциях Azure и работе через шлюз API.

Как добавить шлюз API для ваших Java API, работающих в функциях Azure

К тому времени, когда вы закончите статью выше, вы должны получить доступ к API через Azure APIM, как показано ниже.

Если вы нажмете API, не передав этот ключ в заголовках, вы увидите 401 неавторизованный, как показано ниже.

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

Создание регистраций приложений

Мы развернули Функции Azure и настроили API-шлюз, пора приступить к настройке OAuth 2.0. Первое, что нам нужно сделать, это зарегистрировать два приложения, которые отражают серверную часть и клиент.

Перейдем к регистрации приложений на портале Azure и нажмем кнопку новой регистрации.

Бэкэнд-приложение

Это серверное приложение представляет API. Вы можете указать имя как backend-app и оставить значение URI перенаправления пустым и щелкнуть регистр.

Вы будете перенаправлены на эту страницу и запишите идентификатор приложения.

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

Клиентское приложение

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

Вы будете перенаправлены на эту страницу и запишите идентификатор приложения.

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

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

Наконец, давайте добавим платформу на вкладку «Аутентификация».

Предоставить разрешения

Мы создали две регистрации приложений: client-app и backend-app. Вы должны увидеть и то, и другое в разделе "Регистрация приложений", как показано ниже.

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

Вам нужно добавить разрешение и выбрать серверное приложение, которое мы создали в разделе «Мои API», и, наконец, нажать кнопку «Добавить разрешения». Убедитесь, что вы выбрали область, которую мы создали в серверном приложении.

Настройка OAuth 2.0

Мы завершили регистрацию приложений, и теперь нам нужно настроить OAuth 2.0 в службе управления API. Переходим в службу управления API и щелкаем вкладку OAuth 2.0 + OpenID Connect.

Когда вы нажимаете кнопку добавления, с правой стороны открывается форма. Введем все подробности. Вы можете указать любое имя для отображаемого имени и id. Вам необходимо ввести http: // localhost в качестве URL-адреса страницы регистрации клиента. Проверьте учетные данные клиента в разделе Типы разрешений на авторизацию.

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

Возьмите эти URL-адреса конечных точек и заполните форму, как показано ниже.

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

Вот форма после добавления всего этого и нажатия кнопки создания внизу.

Добавление OAuth 2.0 в API Gateway

Мы создали OAuth 2.0, и нам нужно добавить его в API Gateway для ваших API. Щелкните раздел API, и вам нужно выбрать созданную нами службу OAuth.

Добавление политик для проверки токена

В настоящее время вызов API-интерфейсов через APIM по-прежнему работает без токена. Мы настроили OAuth 2.0, и он должен дать вам код 401, но почему он все еще работает. На этом этапе управление API не проверяет токен доступа.

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

Для URL-адреса OpenID-config перейдем в раздел конечных точек регистраций приложений и возьмем выделенный URL-адрес, как показано ниже.

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

После добавления вышеуказанного политика становится такой, как показано ниже.

Вам необходимо добавить это в раздел политик APIM. Щелкните раздел политик.

Добавьте его во входящий раздел политик и сохраните.

Вы можете увидеть добавленную политику после того, как нажмете кнопку «Сохранить».

Если вы попытаетесь получить доступ к API сейчас, он выдаст вам неавторизованный код, как показано ниже.

Тестирование с почтальоном

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

Даже в почтальоне без жетона получишь такой же результат.

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

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

Имя токена

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

URL-адрес аутентификации и URL-адрес токена доступа

Вы должны получить эти конечные точки из конечных точек регистрации приложений, как показано ниже.

Идентификатор клиента и секрет клиента

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

Сфера

Вы должны ввести указанное ниже значение в качестве области действия. Не забудьте заменить Files.Read на .default.

api://2e9f2367-633a-4890-8659-e1586702c5dd/.default

Нажмите на токен запроса, и вы получите токен, как показано ниже.

Теперь вы можете использовать этот токен для отправки запроса API. Он автоматически добавляется в заголовки запроса, как показано ниже.

Если вы сейчас нажмете API с этим токеном, вы все равно получите код 401, как показано ниже.

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

"accessTokenAcceptedVersion": 2

Убедитесь, что при декодировании токена с помощью любого декодера JWT значение aud должно соответствовать значению, которое мы вводим в политике jwt в шлюзе API, а версия - 2.

Теперь вы можете получить доступ к API с помощью токена, как показано ниже.

Резюме

  • При развертывании веб-приложений или API-интерфейсов в Функциях Azure вы можете либо предоставлять их напрямую из конечной точки Функций Azure, либо обслуживать их через Azure APIM.
  • Первое, что нам нужно сделать, это зарегистрировать два приложения, которые отражают серверную часть и клиент.
  • Это клиентское приложение представляет собой любое клиентское приложение, которое обращается к API.
  • Убедитесь, что вы сохранили секрет клиента где-нибудь, чтобы он больше не появлялся. Если вы его потеряете, вам потребуется создать еще один секрет клиента.
  • На этом этапе управление API не проверяет токен доступа. Вы должны добавить политику в APIM
  • Во время тестирования с почтальоном вы должны выбрать учетные данные клиента в качестве типа предоставления.
  • Убедитесь, что вы добавили 2 к accessTokenAcceptedVersion в файле манифеста клиентского и серверного приложений.

Заключение

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