Простыми словами: как устроена аутентификация/авторизация через Keycloak
При работе с микросервисной архитектурой, тем более в финтехе, системный аналитик рано или поздно столкнется с межсервисной аутентификацией и авторизацией и системами, их обеспечивающими. У нас это Keycloak.
Оказалось, этот зверь полезный, и среди его достоинств - opensource и дружелюбные взаимоотношения с Java.
Keycloak позволяет создавать для разных систем и сред realms, к которым добавляют сущности клиентов (других систем) с присвоением определенных прав. Схема аутентификации/авторизации через Keycloak несложная и чем-то напоминает аутентификацию по сертификатам. Нужно создать клиента системы А в realm системы B, добавить определенные роли и не забыть получить client_secret, по которому система А будет аутентифицироваться уже в самом Keycloak.
А теперь процесс по порядку:
Система А делает запрос на токен в Keycloak (аутентификация по client_id и client_secret).
Keycloak отдает JWT-токен, в котором имеется вся необходимая информация, включая роли и все, что нужно для проверки валидности токена.
Система А передает запрос с указанием в заголовке токена в систему B.
Система B проверяет валидность токена (либо напрямую обращаясь к Keycloak, либо при помощи ранее полученного сертификата).
Если все в порядке и с токеном, и с правами – система B отдает ответ системе А.
Совсем не страшно. Но деталей хватит и на целую статью. Какие вопросы лучше затронуть в ней? Обсудим в комментариях.