❓#ВопросЭксперту: В одном из своих до
кладов т
ы говорил, что рядом со Spring Security в текущее время жив и здравствует Authorization Server. А зачем он нужен, если мы все уже привыкли к Keycloak, а кроме него есть и полноценные решения с поддержкой и обслуживанием вроде Okta?Отвечает эксперт сообщества Spring АйО –
Павел Кислов.
–––Spring Authorization Server - это инструмент, который при прочих равных может быть потенциально гибче. Можно дописать свою логику любую и он будет вести себя так, как вы захотите. Его можно адаптировать под нужды вашей экосистемы и научить делать все необходимые вам "финты". Кроме того, для Spring-разработчика он может быть потенциально понятнее. Если что-то идет не так, можно открыть исходники вашего проекта и подебажить, воспроизведя уязвимость в
"карманном варианте", например. Работа с хранилищем данных настраивается и дописывается. И это огромный плюс. Вот нет у вас вездесущего PostgreSQL. или нужна нереляционная база. По
"исторически сложившимся" причинам, например. Вы можете написать свою имплементацию для нужного сервиса работы с данными и подключить любой источник данных. В Keycloak или Okta мы были бы ограничены.
Еще одним важным аспектом является потенциальная
"лицензия" и коммерческая часть. Выбирая опенсорс решение вроде Keycloak, вы часто остаетесь между двух огней. С одной стороны нет возможности досконально изучить исходники того же Keycloak, хоть он и написан на Java. В него бы пришлось сильно погрузиться и прочитать большое количество исходников, чтобы реализовать свою хотелку, кроме того пришлось бы читать еще и исходники подтянутых им maven-зависимостей. Задача не из легких. С другой стороны он уже готовый этот Keycloak. Разверул и поехали. И в то же время, чтобы понять, как сделать нестандартный ход под ваш конкретный запрос тяжело. Кода много.
Со Spring Authorization Server ты оказываешься в игровой комнате с конструктором в руках. Как собрал, так и поехало. Допустим, не нужен тебе ui - не используй ui. Это просто бекенд приложение.
У вас уже есть ui "с прошлого раза", у которого используются специфичные url? - укажите их в конфигах Authroization Server, и он будет использовать их.
Мы можем
"натянуть сову на глобус", и все это в рамках привычного для нас кода на Spring. Выбрав коммерческое решение, вы часто получаете "закрытую коробочку" и многих это может оттолкнуть. Кроме того, вы отдаете производителю на откуп решение проблем с купленным решением и завяываетесь на сроки вендора. Если вы не делаете rocket science и пользуетесь совсем небольшим количеством возможностей, то, возможно, есть смысл присмотреться к самостоятельной реализации. Это позволяет быстро чиниться и дорабатываться в случае необходимости.
Spring Authorization Server - это совсем не "серебряная пуля" в сравнении с уже имеющимися решениями, а просто возможная альтернатива, развитие и поддержка которой реализуемы и понятны c точки зрения кода для Spring/Java-разработчика. Кстати, Spring предоставляет неплохую документацию к Authorization Server и отличные описания к исходникам на Github, которые подсвечивают все нужные термины и дают прямые ссылки на спецификации, читая которые, можно разобраться в том, как и что на самом деле устроено в
"безопасном" мире.
Отличная пища для ума, поле для изучение и полигон для экспериментов. 
SP 
