Отделите внутреннего пользователя от способов входа: единый user_id и таблица внешних идентичностей provider + subject. Подключайте провайдеров через адаптеры, сохраняя общий контракт сессии для приложений.
Как спроектировать отдельный сервис авторизации, чтобы поддерживать внутренний логин/пароль, Keycloak и в будущем, например, вход через Госуслуги?
Отделите внутреннего пользователя от способов входа: единый user_id и таблица внешних идентичностей provider + subject. Подключайте провайдеров через адаптеры, сохраняя общий контракт сессии для приложений.
Короткий ответ
Что ответить на собеседовании
Подробный разбор
Ответ с пояснениями
Отделите внутреннего пользователя от способов входа: единый user_id и таблица внешних идентичностей provider + subject. Подключайте провайдеров через адаптеры, сохраняя общий контракт сессии для приложений.
Собственный пароль проверяется локальным механизмом, а Keycloak или другой поставщик — через поддерживаемый им протокол и отдельную конфигурацию. Связывание аккаунтов требует доказательства владения, а не простого совпадения неподтверждённого email. Проверяйте issuer, audience, подпись, state/nonce и redirect URI там, где применимо. Для будущего провайдера заранее не придумывайте контракт: предусмотрите расширение адаптера, отказоустойчивость и процедуру отключения без изменения внутреннего идентификатора пользователя.