Почему не использовали готовое решение для авторизации, например Keycloak?

Что проверяют

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

Как отвечать

Сначала развести два разных «своего». Если речь про протоколы (OAuth 2, OIDC, выпуск и отзыв токенов, сброс пароля, второй фактор), самописная реализация почти всегда проигрывает: требований много, а цена ошибки высокая. Разумный вариант звучит так: своё это тонкий слой поверх проверенных библиотек, то есть хеширование пароля через argon2 или bcrypt, готовая библиотека JWT, authlib или штатный механизм фреймворка, а не собственная схема.

Причины не брать именно Keycloak:

• это отдельный сервис на JVM со своей базой. Его надо разворачивать, обновлять и держать доступным, а падение провайдера останавливает вход в продукт;
• расширения пишутся через SPI на Java, и для питоновой команды любая нетиповая логика превращается в чужой стек;
• своя модель пользователей в продукте уже есть, и два источника правды нужно синхронизировать, иначе данные разъезжаются;
• переходы между крупными версиями требуют миграции конфигурации, а администрирование realm это отдельный навык в команде;
• для одного приложения без федерации и корпоративного SSO набор возможностей избыточен.

Сильно звучит названный порог: появились несколько продуктов с общим входом, вход через корпоративный каталог, требования аудита, и тогда внешний провайдер выигрывает.

Где спотыкаются

Аргументируют производительностью: «своё быстрее». Подпись токена проверяется локально по JWKS, на каждый запрос провайдера никто не дёргает, так что различителем это не работает, и встречный вопрос будет неприятным.

Называют Keycloak библиотекой. Это сервер идентификации, и разговор идёт про эксплуатацию и границы ответственности, а не про импорт пакета.

Хвалят полный контроль без деталей. Дальше спросят про хранение паролей, срок жизни и отзыв токенов, ротацию refresh-токенов, защиту от перебора и CSRF. Если ответов нет, полный контроль превращается в полную ответственность, которую нечем закрыть.