Как пройти аутентификацию с помощью OpenID Connect и Apache APISIX

Многие компании стремятся предоставить своего поставщика удостоверений: Twitter, Facebook, Google и т. д. Для небольших компаний отсутствие необходимости управлять удостоверениями является преимуществом. Однако мы хотим избежать привязки к одному провайдеру.

В этом посте я хочу продемонстрировать, как использовать OpenID Connect с помощью Google внизу, а затем переключиться на Azure.

Подключение OpenID

Идея открытого стандарта авторизации началась с OAuth примерно в 2006 году. проблема безопасности, OAuth 2.0 заменил первоначальную версию. OAuth 2.0 стал RFC IETF в 2012 году:

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

— RFC 7469 — Структура авторизации OAuth 2.0

OAuth в основном фокусируется на авторизации; часть аутентификации довольно проста: она содержит раздел об аутентификации с помощью пароля клиента и один раздел о других методах аутентификации.

Сервер авторизации МОЖЕТ поддерживать любую подходящую схему HTTP-аутентификации, соответствующую его требованиям безопасности. При использовании других методов аутентификации сервер авторизации ДОЛЖЕН определить сопоставление между идентификатором клиента (регистрационной записью) и схемой аутентификации.

— 2.3.2. Другие методы аутентификации

OpenID Connect использует OAuth 2.0 и добавляет часть аутентификации:

OpenID Connect 1.0 — это простой уровень идентификации поверх протокола OAuth 2.0. Это позволяет клиентам проверять личность конечного пользователя на основе аутентификации, выполняемой сервером авторизации, а также получать базовую информацию о профиле конечного пользователя совместимым и REST-подобным способом.

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

— Что такое OpenID Connect?

Вот несколько поставщиков удостоверений, совместимых с OpenID Connect:

* Гитхаб * Google * Майкрософт * Яблоко * Фейсбук * Твиттер * Спотифай

Далее мы начнем с Google и переключимся на Azure, чтобы проверить нашу настройку.

Настройка OpenID Connect с Apache APISIX

Представьте, что у нас есть веб-приложение на базе Apache APISIX, которое мы хотим защитить с помощью OpenID Connect. Вот соответствующий файл Docker Compose:

version: "3"

services:
  apisix:
    image: apache/apisix:3.1.0-debian                              #1
    ports:
      - "9080:9080"
    volumes:
      - ./apisix/config.yml:/usr/local/apisix/conf/config.yaml:ro  #2
      - ./apisix/apisix.yml:/usr/local/apisix/conf/apisix.yaml:ro  #3
    env_file:
      - .env
  httpbin:
    image: kennethreitz/httpbin                                    #4

1. Шлюз API Apache APISIX

2. Конфигурация APISIX — используется для статической настройки в следующей строке.

3. Настройте единый маршрут.

4. Веб-приложение для защиты. Подойдет любой.

Apache APISIX предлагает архитектуру на основе подключаемых модулей. Одним из таких подключаемых модулей является подключаемый модуль OpenID-connect, который позволяет использовать OpenID Connect.

Давайте настроим его:

routes:
  - uri: /*                                                                    #1
    upstream:
      nodes:
        "httpbin:80": 1                                                        #1
    plugins:
      openid-connect:
        client_id: ${{OIDC_CLIENTID}}                                          #2
        client_secret: ${{OIDC_SECRET}}                                        #2
        discovery: https://${{OIDC_ISSUER}}/.well-known/openid-configuration   #2#3
        redirect_uri: http://localhost:9080/callback                           #4
        scope: openid                                                          #5
        session:
          secret: ${{SESSION_SECRET}}                                          #6
#END

1. Универсальный маршрут к базовому веб-приложению.

2. Параметры конфигурации плагина. Значения зависят от конкретного поставщика (см. ниже).

3. OpenID Connect может использовать конечную точку обнаружения для получения всех необходимых конечных точек OAuth. Дополнительную информацию см. в спецификации OpenID Connect Discovery 1.0.

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

5. Область действия по умолчанию.

6. Ключ для шифрования данных сеанса. Ставьте что хотите.

Настройка Google для OIDC

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

В Cloud Console создайте специальный проект (или используйте существующий).

Если вы еще этого не сделали, настройте экран согласия OAuth.

В контексте проекта выберите API & Услуги | Учетные данные.

Затем нажмите кнопку + СОЗДАТЬ УЧЕТНЫЕ ДАННЫЕ в верхней строке меню.

Выберите Идентификатор клиента OAuth в меню прокрутки.

Заполните поля:

* Тип приложения: веб-приложение

* Имя: как хотите

* Разрешенные URI перенаправления: <URL>/callback, например,, http://localhost:9080/callback

URL должен быть URL-адресом веб-приложения. Аналогично, /callback должен соответствовать конфигурации подключаемого модуля openid-connect выше.

Обратите внимание, что Google не разрешает относительные URL-адреса, поэтому, если вам нужно повторно использовать приложение в разных средах, вам нужно добавить URL-адрес каждой среды. Нажмите кнопку Создать.

В приведенной выше конфигурации Docker Compose используйте идентификатор клиента и секрет клиента как OIDC_CLIENTID и OIDC_SECRET. Я записал их как переменные среды в файле .env.

Последняя отсутствующая переменная — OIDC_ISSUER: это accounts.google.com. Если вы перейдете на страницу https://accounts.google.com/.well-known/openid-configuration вы увидите все данные, необходимые для OAuth 2.0 (и не только).

Теперь мы можем начать настройку с docker compose up. Когда мы переходим на http://localhost:9080/, браузер перенаправляет нас на страницу аутентификации Google.

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

После этого я могу получить свободный доступ к ресурсу.

Настройка Azure для OIDC

Мой коллега Бобур уже описал все, что нужно сделать, чтобы настроить Azure для OIDC.

Нам нужно только изменить параметры OIDC:

* OIDC_CLIENTID

* OIDC_SECRET

* OIDC_ISSUER: в Azure это должно выглядеть примерно так: login.microsoftonline.com/<TENANT_ID>/v2.0

Если вы перезапустите Docker Compose с новыми параметрами, корневая страница теперь будет защищена с помощью входа в Azure.

Заключение

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

Apache APISIX предлагает подключаемый модуль, который интегрирует ODC, чтобы вы могли защитить свои приложения с помощью последнего. Нет причин не использовать его, так как все специализированные поставщики удостоверений, такие как Okta и Keycloak, совместимы с OIDC.

Полный исходный код для этого сообщения можно найти на GitHub.

Дальше:

* Подключение OpenID * спецификация OpenID Connect Discovery 1.0 * плагин Apache APISIX OIDC * Безопасность API с OIDC с использованием Apache APISIX и Microsoft Azure AD * Используйте Keycloak со шлюзом API для защиты API. * Как использовать аутентификацию Apache APISIX с Okta

Первоначально опубликовано на сайте A Java Geek 5 марта 2023 г.