← назад к разделу

Почти в каждом приложении есть вход: регистрация, пароль, кнопка «забыли пароль?», роли (обычный пользователь и админ). Кажется, что это пара экранов и одна таблица в базе. На деле за этими экранами прячется целый пласт работы, который очень легко сделать неправильно — а ошибка здесь означает дыру в безопасности. Keycloak — это готовый сервис, который берёт весь этот пласт на себя. Разберём с нуля и не торопясь: какую проблему он решает, что означают слова IAM и SSO, и где Keycloak стоит относительно вашего приложения и API.

Проблема: «напишу авторизацию сам»

Давайте честно посмотрим, что значит «сделать вход самому». Когда логин пишут руками, в проекте постепенно появляется такой список задач:

  • хранить пароли — но не сам пароль, а его хеш с солью, иначе при утечке базы утекут все пароли;
  • сделать регистрацию, вход, выход, смену пароля и сброс пароля по почте;
  • завести роли (кто обычный пользователь, кто администратор) и проверять права на каждой странице и в каждом запросе;
  • защититься от перебора паролей, от угона чужой сессии, от утечки токенов;
  • а потом, когда бизнес попросит, — добавить вход через Google, второй фактор (одноразовый код из приложения), блокировку учётной записи.

Каждый пункт по отдельности выглядит несложным. Беда в двух вещах. Первая: таких пунктов десятки, и ошибка в любом из них — это не «некрасивая кнопка», а уязвимость, через которую могут войти под чужим именем. Вторая: как только у вас появляется второе приложение, весь этот код приходится писать заново или копировать из проекта в проект — а вместе с кодом копируются и ошибки.

Вывод напрашивается сам: вход — это не «фича приложения», а отдельная самостоятельная задача. И раз она у всех одинаковая, логично взять готовое решение, а не изобретать своё.

Что такое Keycloak

Keycloak — это отдельный готовый сервис, которому вы передаёте всю работу со входом. Его разрабатывает Red Hat, он бесплатный и с открытым исходным кодом. После подключения Keycloak ваше приложение перестаёт хранить пароли и заниматься входом. Оно лишь спрашивает у Keycloak один вопрос: «этот человек — кто, и что ему можно?»

Аналогия из жизни. Представьте бизнес-центр с десятком офисов. Раньше каждый офис держал на двери своего охранника, который проверял паспорта и вёл свой журнал посетителей. Это дорого, и охранники проверяют по-разному. Keycloak — это одна общая проходная на входе в здание. Вы один раз показываете документ на проходной, получаете пропуск-бейдж, и дальше ходите по офисам, показывая уже бейдж, а не паспорт. Офисы вообще не видят ваш паспорт — они доверяют проходной.

В этой аналогии:

  • проходная — это Keycloak;
  • паспорт — это ваш логин и пароль;
  • бейдж-пропуск — это токен, который выдаёт Keycloak;
  • офисы — это ваши приложения и сервисы.

IAM и SSO простыми словами

Вокруг Keycloak часто звучат две аббревиатуры — разберём их без жаргона.

IAM расшифровывается как Identity and Access Management — «управление личностями и доступом». Это общее название для всего, что отвечает на два вопроса: «кто это за человек» (личность, identity) и «что ему разрешено» (доступ, access). Keycloak — это IAM-система: он и хранит учётные записи, и решает, кому что можно. Когда говорят «у нас Keycloak как IAM», имеют в виду ровно это — единое место, где живут пользователи и их права.

SSO расшифровывается как Single Sign-On — «единый вход». Это удобство для пользователя: войти один раз и получить доступ сразу ко всем приложениям, не вводя пароль в каждом заново.

Поясним на боли. У компании пять внутренних приложений, и в каждом — свой экран входа. Сотрудник вводит пароль пять раз и держит в голове пять разных паролей. С SSO он входит один раз через Keycloak, а все приложения, подключённые к нему, узнают сотрудника автоматически. Вышел из одного приложения — вышел сразу из всех. Это удобнее людям и безопаснее для компании: учётная запись одна, и если сотрудник уволился, заблокировать его можно в одном месте, а не бегать по пяти системам.

Связь простая: IAM — это про то, что Keycloak делает (управляет личностями и доступом). SSO — это одно из главных удобств, которое из этого вытекает (один вход на все приложения).

Где Keycloak стоит относительно приложения и API

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

  • Keycloak проверяет, кто пользователь (логин и пароль), и выдаёт ему «пропуск» — токены.
  • Ваше приложение пароль не проверяет вообще. Оно получает токен и проверяет только, что пропуск настоящий и не просрочен.
  • Ваш API (бэкенд, куда приложение ходит за данными) принимает токен в каждом запросе и по нему решает, отдавать данные или нет.

Дальше — что на схеме. Пользователь работает с приложением; приложение отправляет его залогиниться в Keycloak; Keycloak проверяет пароль и выдаёт токены обратно приложению; затем приложение ходит в защищённый API, прикладывая к каждому запросу заголовок Authorization: Bearer access_token — и API проверяет этот токен. Keycloak в центре как единый поставщик личности.

diagram

Обратите внимание на главное: стрелка с паролем идёт только в Keycloak. Ваш API пароль никогда не видит — он видит только токен. Это и есть смысл всей затеи: один сервис отвечает за вход, остальные ему доверяют по токену.

Что за «пропуск», который выдаёт Keycloak

Тот самый бейдж-пропуск из аналогии — это токен. Чаще всего Keycloak выдаёт его в формате JWT: это строка, внутри которой в читаемом виде лежат имя пользователя, его роли и срок годности, а в конце — цифровая подпись Keycloak. Приложение или API убеждается, что подпись настоящая, и после этого доверяет содержимому: «да, подпись Keycloak верна, значит это действительно роли этого человека».

Если совсем коротко, токенов на самом деле несколько, и у каждого своя роль:

  • access_token — главный «рабочий пропуск». Именно его приложение кладёт в заголовок Authorization: Bearer ... при обращении к API. По нему API понимает, кто пришёл и что ему можно.
  • id_token — отвечает на вопрос «кто именно вошёл» и предназначен для самого приложения, чтобы показать имя пользователя в интерфейсе. В API его не отправляют.
  • refresh_token — нужен, чтобы получить новый access_token, когда старый протух, не заставляя пользователя вводить пароль снова. Его отправляют только обратно в Keycloak.

Не пугайтесь, если пока не уложилось, — устройство токенов это отдельная большая тема (см. ссылки в конце). Здесь важна одна мысль: вход и проверка входа — это разные роли разных систем, а связывает их токен.

Что Keycloak даёт из коробки

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

Единый вход (SSO)

Это мы уже разобрали выше: пользователь входит один раз, все подключённые приложения узнают его без повторного ввода пароля, а выход из одного означает выход из всех. Для пользователя — удобство, для компании — единая точка управления учётными записями.

OAuth2 и OpenID Connect из коробки

Это два стандартных протокола — то есть общепринятые «правила разговора», по которым приложения и Keycloak договариваются о входе. Их ценность в том, что не нужно изобретать свой формат: Keycloak уже умеет говорить на общем языке, который понимают все.

  • OAuth2 отвечает на вопрос «что этому пользователю можно делать» — то есть про доступ и разрешения.
  • OpenID Connect (OIDC) — это надстройка над OAuth2, которая добавляет ответ на вопрос «кто это» — то есть про личность и сам факт входа. На практике для логина используют именно OIDC.

Почему это важно на практике: раз протоколы стандартные, к Keycloak без проблем подключаются и фронтенд на React, и мобильное приложение, и бэкенд на Spring — все они понимают OAuth2/OIDC. Вы не привязаны к одной технологии и можете менять её части независимо.

Управление пользователями и ролями

В Keycloak есть готовый раздел администрирования — веб-интерфейс, где можно:

  • заводить и блокировать пользователей, сбрасывать им пароли;
  • создавать роли (например, customer, seller, admin) и назначать их людям;
  • объединять пользователей в группы для удобства;
  • настраивать политику паролей и второй фактор (одноразовый код).

И всё это — без единой строчки вашего кода. Роли, которые вы назначили человеку, Keycloak кладёт внутрь токена, а приложение по ним решает, что пользователю разрешено. Важный побочный плюс: управлять пользователями могут не программисты, а администраторы — через интерфейс, а не через правки в базе.

Вход через соцсети и подключение чужих систем

Federation (федерация) — это возможность пускать в приложение пользователей, которые хранятся не в самом Keycloak, а где-то ещё.

  • Social login — те самые кнопки «Войти через Google / GitHub / VK». Keycloak сам общается с этими сервисами по их правилам, а вам не нужно разбираться с каждым по отдельности.
  • Подключение корпоративного каталога — например, LDAP или Active Directory. Сотрудники входят под своими рабочими учётными записями, а Keycloak выступает посредником между вашим приложением и этим каталогом.

Принцип тот же, что и со всем остальным: разнообразие источников входа Keycloak прячет за собой, а вашему приложению отдаёт один понятный токен. Приложению вообще не важно, вошёл человек по паролю, через Google или по корпоративной учётке, — оно видит лишь токен.

Из чего состоит Keycloak

Устройство простое — по сути две части плюс пара понятий.

  • Сервер Keycloak — само приложение, которое запускается отдельно (часто в контейнере). Оно показывает пользователям страницы входа, проверяет пароли и выдаёт токены. Ему нужна своя база данных, где хранятся учётные записи и настройки.
  • Административная консоль — веб-интерфейс для настройки. Через него заводят пользователей, роли, подключают приложения и соцсети. Технически это просто страницы того же сервера.

И два понятия, которые встретятся вам с первых минут работы:

  • Realm (можно понимать как «область» или «пространство») — изолированный набор пользователей, ролей и настроек. Один realm не видит пользователей другого. Это удобно, когда на одном сервере нужно разделить, например, сотрудников и внешних клиентов, или несколько независимых проектов.
  • Client (клиент) — это запись о конкретном приложении, которое подключается к Keycloak. Каждый фронтенд, бэкенд или мобильное приложение регистрируется как отдельный client внутри realm.

Структура получается такая: на сервере есть один или несколько realm, в каждом realm — свои пользователи и роли и список client (подключённых приложений). Подробно про realm, client и роли — в отдельной статье серии.

Как приложение подключается к Keycloak

Подключение — это в основном настройка, а не код. Покажем общую картину на примере бэкенда. Приложению на Spring достаточно сказать, где живёт Keycloak, и оно само научится проверять токены:

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://keycloak.example.ru/realms/marketplace

Здесь issuer-uri — это адрес вашего realm в Keycloak. По этому адресу Spring сам находит публичные ключи Keycloak (их набор называется JWKS — набор ключей для проверки подписи) и дальше проверяет подпись каждого токена локально, не обращаясь к Keycloak на каждый запрос. Ключи скачиваются один раз и держатся в памяти; если Keycloak сменит ключ — Spring подтянет новый автоматически. Это важно для скорости: проверка токена не зависит от того, доступен ли сейчас Keycloak.

Главная мысль остаётся прежней: логику входа писать не нужно — её уже написали в Keycloak. Ваша задача — указать адрес и доверять токенам, которые он подписал.

Когда Keycloak нужен, а когда избыточен

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

Keycloak оправдан, когда:

  • приложений несколько и хочется один вход на всех (SSO);
  • нужен вход через соцсети, второй фактор или подключение к корпоративному каталогу;
  • пользователей и ролей много, и управлять ими должны администраторы, а не программисты;
  • безопасность входа критична и не хочется писать её самому.

Keycloak избыточен, когда:

  • проект маленький, приложение одно, пользователей десятки;
  • вход простой и без планов на соцсети и второй фактор;
  • нет ресурсов поддерживать ещё один сервис и базу под него.

Для маленького проекта отдельный сервер входа — это лишняя сложность: проще обойтись встроенными средствами вашего фреймворка. Keycloak начинает окупаться тогда, когда вход перестаёт быть «парой экранов» и становится самостоятельной задачей со своими требованиями.

Коротко

  • Keycloak — отдельный готовый сервис входа (IAM-система), который забирает у вашего приложения хранение паролей и логику авторизации.
  • IAM — управление личностями и доступом (кто это и что ему можно); SSO — единый вход: один логин на все приложения.
  • Приложение не проверяет пароль — пароль видит только Keycloak. Приложение и API получают подписанный токен (обычно JWT) и проверяют его подлинность.
  • Keycloak стоит сбоку как единый поставщик личности: пользователь → приложение → Keycloak за токенами, затем приложение → API с заголовком Authorization: Bearer access_token.
  • Токенов несколько: access_token идёт в API, id_token — для самого приложения, refresh_token — только обратно в Keycloak.
  • Из коробки: SSO, протоколы OAuth2/OIDC, управление пользователями и ролями, вход через соцсети и подключение корпоративных каталогов (federation).
  • Состоит из сервера (выдаёт токены, нужна база) и админ-консоли. Внутри: realm — изолированное пространство, client — запись о подключённом приложении.
  • Подключение — это в основном настройка (issuer-uri на realm), а не код; токены проверяются локально по ключам JWKS.
  • Keycloak оправдан при нескольких приложениях, соцсетях, втором факторе, многих ролях; для маленького проекта с одним простым входом он избыточен.

Что почитать дальше

  • OAuth2 и OIDC простыми словами — что это за протоколы и чем они отличаются.
  • Realm, client, роли и пользователи в Keycloak — устройство сервера изнутри.
  • Authorization Code Flow и PKCE — как именно приложение получает токены.
  • Токены Keycloak: проверка, refresh, отзыв и ошибки — что внутри токена и как с ним обращаться.
  • Keycloak и Spring Security: проверка токенов — подключение на стороне бэкенда.
  • Роли и доступ: RBAC и ABAC с Keycloak — как раздавать права в приложении.