Realms

Деление на блоки через realm. Каждый realm изолирован, пользователь принадлежит только одному realm. Содержит конфигурацию, набор приложений и пользователей. Есть административный и остальные realm.

Master: административный realm, задачи:

Управления другими realms (создание, удаление и настройка realms, управление пользователями-администраторами)
Создание глобальных админов. Роли realm-admin, admin, create-realm и т. д. позволяют входить в Keycloak Admin Console (/admin) и управлять сервером.
Использование Keycloak'ом для внутренних задач. Системные клиенты и сервисные аккаунты находятся в master realm.
Примеры: admin-cli, account, broker.

Есть консоль управления реалм.

Создание realm

Настройка realm в момент создания - только имя

Имя не должно содержать пробелов и иных символов, плохо воспринимаемых в url адресе.

Настройка realm (realm settings)

В меню Manage realms выбирается реалм, который мы будем редактировать.
Затем в левом меню, раздел Configure содержит 4 блока.

OpenID Endpoint configuration - здесь можно увидеть все endpoint настроенные для данного realm.

Настройка процесса аутентификации. Раздел Authentication используется для настройки и управления потоками аутентификации, обязательными действиями, и политиками входа.
Authentication flow (поток аутентификации) - это набор шагов, через которые проходит пользователь или клиент при входе, регистрации, сбросе пароля и т.д. Каждый поток состоит из действий (executions): например, проверка пароля, OTP, условные переходы, выбор IdP и др.

Потоки создаются и настраиваются.

Типы токенов

Access Token - доступ к API
- Opaque. непрозрачный токен (например, 8fa3b2e1-cb4e-4fd7-b517-84fc4c2f3a77). Клиент не может сам понять, что в токене. Чтобы узнать, что за пользователь и какие у него права, ресурсный сервер обязан обратиться к серверу авторизации (например, через /introspect endpoint). Плюсы: безопаснее (минимальные утечки данных через токен), легче отозвать токен централизованно. Минусы: нужен дополнительный сетевой вызов для валидации токена, больше нагрузка на сервер авторизации.
- JWT самостоятельный токен, в себе несёт всю информацию (пользователь, права, срок жизни и т.д.). Токен подписан (обычно RS256 или HS256), и ресурсный сервер может проверить его сам, без запроса к серверу авторизации. Плюсы: нет лишних сетевых вызовов на проверку и быстрее работает на стороне ресурсных серверов. Минусы: выданный токен нельзя "убить" мгновенно (если только через сложные механизмы типа revocation lists) и токен может содержать чувствительную информацию - важно правильно шифровать или минимизировать payload. Есть сайт jwt.io для просмотра данных из токена.
Refresh Token - продление действия access token. Отправляется на сервер и сессия продлевается.
ID Token - (только в OIDC) информация о пользователе

Grant Type - способ, получения Access Token от сервера авторизации в OAuth 2.0 / OpenID Connect. Тип разрешения (grant) определяет, как и при каких условиях клиент получает токены. Keycloak, как реализация Identity Provider и Authorization Server, поддерживает разные grant types (, ).

Название	Описание	Тип приложения
Authorization Code	Стандартный безопасный flow для веб-приложений, где сервер клиента может хранить секреты. Клиент формирует POST-запрос к token-эндпоинту авторизационного сервера с обязательными параметрами: grant_type -> Authorization Code authorization_code -> code, полученный на шаге 6 redirect_uri -> тот же URI, что использовался при авторизации client_id -> Идентификатор клиента client_secret -> Секрет клиента безопасно для серверов с хранением Client Secret. Уязвимость на этапе редиректа. Подходит для серверных приложений	Веб-приложения (backend + frontend).
Authorization Code + PKCE	Модификация Authorization Code Flow для публичных клиентов (например, мобильных и SPA), чтобы предотвратить атаку перехвата кода. Клиент перед началом авторизации: Генерирует случайный код (code_verifier) Строит на его основе code_challenge (обычно SHA-256) При первом запросе отправляется code_challenge При обмене Authorization Code на Access Token отправляется code_verifier. Authorization Server сверяет code_challenge и code_verifier: Если всё сходится, только тогда выдает Access Token. Это защищает от атаки перехвата кода, потому что даже если злоумышленник украдет Authorization Code, без правильного code_verifier он не сможет обменять его на Access Token. безопасно для мобильных и браузерных клиентов без секретов. Нужен только Code Verifier Защита на этапе редиректа Подходит для мобильных и SPA	Мобильные приложения, SPA (Single Page Applications).
Client Credentials	Классический machine-to-machine сценарий, когда приложение запрашивает токен от собственного имени, без пользователя.	Сервисные взаимодействия (backend to backend), микросервисы.
Device Code	Для устройств без полноценной клавиатуры (например, Smart TV). Пользователь вводит код на другом устройстве.	Устройства с ограниченным вводом - SmartTV, консоли, IoT.
Refresh Token	После получения Access Token можно получить новый токен без повторной аутентификации пользователя.	Любые клиенты с долгоживущими сессиями.

User Federation

Используется для подключения к внешним источникам пользователей (LDAP, Active Directory или Kerberos). С помощью федерации:

пользователи остаются в LDAP/AD/Kerberos;
Keycloak может их аутентифицировать;
можно синхронизировать или кэшировать данные (имя, email, роли и т.д.);
поддерживается одноразовый вход (SSO), если внешняя система это позволяет.

SAML

Security Assertion Markup Language - открытый стандарт SSO между разными доменами. Позволяет аутентифицироваться в одной системе и получить доступ к другой, предоставив подтверждение своей аутентификации. Используется с 2005 года и остаётся популярным для федерации идентичности в B2B и B2E-сценариях, особенно в государственном и корпоративном секторе. SAML оперирует:

XML - для описания данных пользователя
HTTP - как транспортный протокол