Интеграция OAuth2 Server

Исследуем работу готового компонента League OAuth2 Server и проинтегрируем его в наш PHP-проект. Напишем требуемые сущности и репозитории по интерфейсам компонента. Добавим сохранение авторизационного кода и токена обновления через Doctrine.

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

  • 00:00:42 - Механика аутентификации
  • 00:04:10 - Обновление зависимостей
  • 00:06:12 - Обновление Docker-образов
  • 00:08:18 - Доставание переменных окружения
  • 00:10:17 - Пользовательская функция env
  • 00:14:39 - Обзор League OAuth2 Server
  • 00:17:53 - План интеграции компонента
  • 00:21:31 - Требуемые репозитории
  • 00:30:45 - Готовый пример интеграции
  • 00:36:05 - Добавление сущностей
  • 00:41:47 - Написание репозиториев
  • 00:46:13 - Сохранение через Doctrine ORM
  • 00:54:05 - Фиксированные клиенты и области
  • 00:55:10 - Генерация миграции
  • 00:56:57 - Код сохранения в репозиториях
  • 01:01:14 - Создание компонента сервера

В следующем эпизоде спрограммируем контроллеры для страницы авторизации и для выпуска токенов. И разберёмся с добавлением Query-модели для запросов данных из модулей по аналогии с уже имеющимися командами Command.

Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Комментарии (11)
Arunas

Спасибо.

Ответить
fedot

Спасибо!

Ответить
Руслан

Спасибо!

Ответить
Максим (@myks92)

Дмитрий, я в своём проекте на Symfony миграции и конфигурации модуля храню прямо в папке модуля. Например, src/Auth/config.php и миграции src/Auth/Data/Migration. Очень помогает когда требуется скопировать в другой проект весь модуль. При этом все миграции будут соблюдены и так же зафиксируются в своих таблицах auth_migrations. Вы не планируете разделить так же?

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

Ответить
Дмитрий Елисеев

Миграции и конфигурации модуля храню прямо в папке модуля.

Такая возможность указывать несколько путей миграций появилась не так давно. Ещё не успели перейти.

Ответить
Дмитрий Елисеев

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

Когда появится несколько модулей, тогда сделаем так.

Ответить
Руслан

Дмитрий, здравствуйте,

а что если в данном проекте выделить сервер аутентификации и авторизации в отдельный сервис, который будет в дальнейшем легче отдельно поддерживать/обновлять, а в сервис api оставить на обслуживание основной бизнес-логики?

Это даст дополнительные возможности, такие как переиспользовать его в других сервисах при их появлении, более тонко мониторить и распределять нагрузку необходимую на аутентификацию и остальное api, при необходимости централизованно перейти на другой стандарт/протокол, либо подменить реализацию на стороннее решение (Keycloak etc.). К тому же в проекте уже используется Traefik, как раз можно будет полноценно задействовать его middleware для аутентификации.

Если это расходится с целями данного проекта, может сделаете отдельный урок или стрим как это лучше сделать на другом примере?

Спасибо!

Ответить
Дмитрий Елисеев

выделить сервер аутентификации и авторизации в отдельный сервис

Да, как раз многие порталы такое делают. В этом проекте у нас модульный монолит, где всё вместе, а не разбивка на сервисы.

может сделаете отдельный урок или стрим как это лучше сделать на другом примере?

Просто вынести в отдельный репозиторий код для Auth и OAuth и деплоить его на отдельный поддомен вроде auth или id. И потом подставить тот адрес в переменную окружения AUTH_URL фронтенда.

Ответить
Руслан

Дима, спасибо, не совсем ясно как тогда защитить доступ к api, который остался публичным, проверять токены дергая из него сервис Auth/OAuth, либо достаточно использовать JWT, или что еще? Спасибо!

Ответить
Дмитрий Елисеев

JWT подписывается приватным ключом, а потом проверяется публичным.

Поэтому в auth-сервис выносим AuthorizationServer с приватным ключом.
А всем API-сервисам оставляем ResourceServer с публичным.

Ответить
Руслан

Спасибо!

Ответить
Зарегистрируйтесь или войдите чтобы оставить комментарий

Или войти через:

Google
GitHub
Yandex
MailRu