Интеграция 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 - Создание компонента сервера
Скрытый контент (код, слайды, ...) для подписчиков. Открыть →
Дмитрий Елисеев
elisdn.ru
Чтобы не пропускать новые эпизоды подпишитесь на наш канал @deworkerpro в Telegram
Спасибо.
Спасибо!
Спасибо!
Дмитрий, я в своём проекте на Symfony миграции и конфигурации модуля храню прямо в папке модуля. Например,
src/Auth/config.phpи миграцииsrc/Auth/Data/Migration. Очень помогает когда требуется скопировать в другой проект весь модуль. При этом все миграции будут соблюдены и так же зафиксируются в своих таблицахauth_migrations. Вы не планируете разделить так же?Видел, что Валентин Удальцов на Symfony тоже конфиг файл модуля хранит в модуле, а не общей папке. Так же смотрел Ваш доклад на PHPBear, где было предложено хранить конфигурации прямо в модуле, однако не понял почему решили уйти от этого.
Такая возможность указывать несколько путей миграций появилась не так давно. Ещё не успели перейти.
Когда появится несколько модулей, тогда сделаем так.
Дмитрий, здравствуйте,
а что если в данном проекте выделить сервер аутентификации и авторизации в отдельный сервис, который будет в дальнейшем легче отдельно поддерживать/обновлять, а в сервис api оставить на обслуживание основной бизнес-логики?
Это даст дополнительные возможности, такие как переиспользовать его в других сервисах при их появлении, более тонко мониторить и распределять нагрузку необходимую на аутентификацию и остальное api, при необходимости централизованно перейти на другой стандарт/протокол, либо подменить реализацию на стороннее решение (Keycloak etc.). К тому же в проекте уже используется Traefik, как раз можно будет полноценно задействовать его middleware для аутентификации.
Если это расходится с целями данного проекта, может сделаете отдельный урок или стрим как это лучше сделать на другом примере?
Спасибо!
Да, как раз многие порталы такое делают. В этом проекте у нас модульный монолит, где всё вместе, а не разбивка на сервисы.
Просто вынести в отдельный репозиторий код для Auth и OAuth и деплоить его на отдельный поддомен вроде
authилиid. И потом подставить тот адрес в переменную окружения AUTH_URL фронтенда.Дима, спасибо, не совсем ясно как тогда защитить доступ к api, который остался публичным, проверять токены дергая из него сервис Auth/OAuth, либо достаточно использовать JWT, или что еще? Спасибо!
JWT подписывается приватным ключом, а потом проверяется публичным.
Поэтому в auth-сервис выносим
AuthorizationServerс приватным ключом.А всем API-сервисам оставляем
ResourceServerс публичным.Спасибо!
Или войти через: