Комментарии 7
Хорош, побольше бы таких темплейтов полезных.
А есть пример с использованием Oidc и МФА?
А если у меня несколько ресурсов с авторизацией, то как быть в этом случае? Копипастить из модуля в модуль логику проверки токена (пакет auth) или можно вынести ее в отдельный сервис, и дергать его из каждого ресурса, например через RestTemplate?
Статья вызывает очень много вопросов. Во-первых: а вы уверены, что это именно Oauth 2.0, а не его вольная интерпретация?
протокол авторизации oauth 2 (частично)
То, что описано у вас в статье больше похоже на попытку реализации своего Resource Owner Password Credentials, небезопасного и нерекомендуемого к использованию, а Oauth 2.1 так и вовсе запрещённого. Настоящий Oauth 2.0 для веб приложений - это authorization code со всей цепочкой редиректов. Ваша реализация не имеет ничего общего с этим флоу.
Второе: для чего понадобилось делать свой AuthService - без нормальной поддержки Oauth 2.0, безопасных веб-сессий, OIDC и т.д.? Почему нельзя было взять тот же keycloak или Spring Authorization Server? Это мощные проверенные временем технологии с большим комьюнити, надежно зарекомендовавшие себя в продакшн-условиях. Ваш AuthService не удовлетворяет даже 5% от тех требований, которые предъявляются к реальным серверам авторизации.
1. Сприг-секьюрити слишком подвержен изменениям. Постоянно выходят новые версии, старые методы становятся неподдерживаемыми, возникают новые классы и так далее. С моей точки зрения это говорит о том, что данный проект ещё несколько сыроват.2. Использование сприг-секьюрити накладывает дополнительные архитектурные ограничения. Иногда эти ограничения идут в разрез с планируемой архитектурой.3. Наконец что если я хочу написать действительно "микро"-сервис, то есть вообще без использования спринга?
По пунктам:
В spring-security депрекейтед апи может присутствовать годами. Есть компоненты еще с первых релизов. Удаляются такие компоненты крайне редко, чтобы лишний раз не нарушать обратную совместимость. То, что появляются новые классы - неудивительно, фрэймворк развивается, появляются новые фичи - тот же webauth или one time token login. Вы считаете, что развитие технологии это минус? Это я вам говорю как один из разработчиков spring-security.
Например, какие? То, что нужно настроить SecurityFilterChain не заставит ваш сервис работать кардинально иначе. Если только вы не используете свою велосипедную авторизацию вместо oauth 2.0. Но как показала практика, даже в таких случаях spring security прекрасно работает.
Никто не запрещает. правда возникает вопрос - какова цена такой разработки.
Со шлюзом тоже странная ситуация: есть TokenRelay для oauth клиентов и это, то как нужно строить систему авторизации для веб-приложений. У вас же опять что-то сильно странное и неочевидное.
В общем, извините за критику, но в данном случае "Платон мне друг но истина дороже". Ваше решение мне видится крайне сомнительным.
> Ваш AuthService не удовлетворяет даже 5% от тех требований, которые предъявляются к реальным серверам авторизации.
Согласен, но всё же замечу что свою функцию - быть единой точкой авторизации, он всё-таки выполняет. В большинстве случаев это единственное что требуется от сервиса авторизации.
Можете ли вы сказать что-нибудь насчёт небезопасности или прямой уязвимости такого подхода? Замечу, что вопрос именно об уязвимости. Отсутствие дополнительной функциональности не является уязвимостью.
>появляются новые классы - неудивительно, фрэймворк развивается, появляются новые фичи .
Я сравниваю количество изменений (если хотите количество depricated) между различными версиями различных проектов и изменений в spring security от версии к версии видится на порядок больше. Возможно это субъективное впечатление.
Реестр сервисов, например spring cloud eureka. Впрочем, рискну утверждать что он вам не нужен если вы используете доккер-контейнеры и хоть какую-то систему оркестрации, хотя бы даже docker compose), а лучше что типа kubernetes
Почему? Я с инфраструктурой эврики недавно только познакомился. И соответственно микросервисы разворачивал докером в контейнерах вместе с реестром. Все нормально было. Можно ли получить подробный коммент?
Реестр сервисов нужен чтобы сопоставлять ip или имя-хоста с конкретным сервисом. Но если мы имеем возможность руками задавать имя виртуального хоста, то зачем нам реестр сервисов?
Конкретный пример: пусть у нас есть старая версия сервиса v1 которая работает на хосте предыдущая-версия и новая версия v2 которая работает на хосте актуальная-версия.
Пусть у нас появляется ещё более новая версия сервиса v3. Тогда мы просто выводим из эксплуатации хост предыдущая-версия. Хост актуальная-версия переименовываем в предыдущая-версия, а для новейшей версии сервиса v3 создаём новых хост по имени актуальная-версия.
Всё. Никаких настроек маршрутизации не требуется.
Я не говорю что реестр сервисов - плохо. Наоборот, реестр сервисов -хорошо. Он решает свою задачу. Просто, его применение часто может быть избыточно.
Simple Spring (полный фарш)