# 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.

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

**<span style="color: rgb(0, 0, 0);">Создание realm</span>**

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

[![image.png](http://bobrobotirk.ru/uploads/images/gallery/2026-04/scaled-1680-/YbFimage.png)](http://bobrobotirk.ru/uploads/images/gallery/2026-04/YbFimage.png)

 <span style="color: rgb(0, 0, 0);">Имя не должно содержать пробелов и иных символов, плохо воспринимаемых в url адресе.</span>

**<span style="color: rgb(0, 0, 0);">Настройка realm (realm settings)</span>**

<span style="color: rgb(0, 0, 0);">В меню Manage realms выбирается реалм, который мы будем редактировать. Затем в левом меню, раздел Configure содержит 4 блока.</span>

<span style="color: rgb(0, 0, 0);">OpenID Endpoint configuration - здесь можно увидеть все endpoint настроенные для данного realm. </span>

[![изображение.png](http://bobrobotirk.ru/uploads/images/gallery/2025-11/scaled-1680-/Mfcizobrazenie.png)](http://bobrobotirk.ru/uploads/images/gallery/2025-11/Mfcizobrazenie.png)

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

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

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

<table border="1" id="bkmrk-%D0%9D%D0%B0%D0%B7%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-%D0%A2%D0%B8" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 17.5209%;"></col><col style="width: 64.3552%;"></col><col style="width: 18.1239%;"></col></colgroup><thead><tr><td>Название</td><td>Описание</td><td>Тип приложения</td></tr></thead><tbody><tr><td>Authorization Code</td><td>Стандартный безопасный flow для веб-приложений, где сервер клиента может хранить секреты. Клиент формирует POST-запрос к token-эндпоинту авторизационного сервера с обязательными параметрами:

- grant\_type -&gt; Authorization Code
- authorization\_code -&gt; code, полученный на шаге 6
- redirect\_uri -&gt; тот же URI, что использовался при авторизации
- client\_id -&gt; Идентификатор клиента
- client\_secret -&gt; Секрет клиента

безопасно для серверов с хранением Client Secret. Уязвимость на этапе редиректа. Подходит для серверных приложений

</td><td>Веб-приложения (backend + frontend).</td></tr><tr><td>Authorization Code + PKCE</td><td>Модификация 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

</td><td>Мобильные приложения, SPA (Single Page Applications).</td></tr><tr><td>Client Credentials </td><td>Классический machine-to-machine сценарий, когда приложение запрашивает токен от собственного имени, без пользователя.</td><td>Сервисные взаимодействия (backend to backend), микросервисы.</td></tr><tr><td>Device Code</td><td>Для устройств без полноценной клавиатуры (например, Smart TV). Пользователь вводит код на другом устройстве.</td><td>Устройства с ограниченным вводом - SmartTV, консоли, IoT.</td></tr><tr><td>Refresh Token</td><td>После получения Access Token можно получить новый токен без повторной аутентификации пользователя.</td><td>Любые клиенты с долгоживущими сессиями.</td></tr></tbody></table>

**Authentication**

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

<table border="1" id="bkmrk-%D0%9D%D0%B0%D0%B7%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5-%D0%9E%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%B8%D0%B5-br" style="border-collapse: collapse; width: 100%;"><colgroup><col style="width: 21.4541%;"></col><col style="width: 78.5459%;"></col></colgroup><thead><tr><td>Название</td><td>Описание</td></tr></thead><tbody><tr><td>browser</td><td>Встроенный поток для авторизации на основе браузера. <span id="bkmrk-%D0%92%D0%BA%D0%BB%D1%8E%D1%87%D0%B0%D0%B5%D1%82-%D1%84%D0%BE%D1%80%D0%BC%D1%8B-%D0%BB%D0%BE%D0%B3%D0%B8%D0%BD">Включает формы логина, OTP (двухфакторную аутентификацию), CAPTCHA и другие шаги.</span></td></tr><tr><td>clients</td><td><span id="bkmrk-%D0%92%D1%81%D1%82%D1%80%D0%BE%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9-%D0%BF%D0%BE%D1%82%D0%BE%D0%BA-%D0%B0%D1%83%D1%82">Встроенный поток аутентификации для клиентов (используется в client credentials grant). Работает без участия пользователя.</span></td></tr><tr><td>direct grant</td><td><span id="bkmrk-%D0%92%D1%81%D1%82%D1%80%D0%BE%D0%B5%D0%BD%D0%BD%D1%8B%D0%B9-%D0%BF%D0%BE%D1%82%D0%BE%D0%BA-%D0%B4%D0%BB%D1%8F">Встроенный поток для ресурсного владельца (Resource Owner Password Credentials Grant). Используется, когда пользователь напрямую вводит логин и пароль (например, через curl или мобильное приложение).</span></td></tr><tr><td>docker auth</td><td><span id="bkmrk-%D0%9F%D0%BE%D1%82%D0%BE%D0%BA-%D0%B0%D1%83%D1%82%D0%B5%D0%BD%D1%82%D0%B8%D1%84%D0%B8%D0%BA%D0%B0%D1%86%D0%B8%D0%B8">Поток аутентификации Docker-клиентов при доступе к приватному Docker Registry через Keycloak.</span></td></tr><tr><td><span id="bkmrk-first-broker-login">First broker login</span></td><td><span id="bkmrk-%D0%9F%D0%BE%D1%82%D0%BE%D0%BA%2C-%D1%81%D1%80%D0%B0%D0%B1%D0%B0%D1%82%D1%8B%D0%B2%D0%B0%D1%8E%D1%89%D0%B8%D0%B9">Поток, срабатывающий при первом входе пользователя через внешний Identity Provider (например, Google, GitHub). Позволяет привязать внешний аккаунт к локальному пользователю Keycloak.</span></td></tr><tr><td><span id="bkmrk-registration"><span id="bkmrk-registration-1">Registration</span></span></td><td><span id="bkmrk-%D0%9F%D0%BE%D1%82%D0%BE%D0%BA-%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%86%D0%B8%D0%B8-%D0%BD%D0%BE"><span id="bkmrk-%D0%9F%D0%BE%D1%82%D0%BE%D0%BA-%D1%80%D0%B5%D0%B3%D0%B8%D1%81%D1%82%D1%80%D0%B0%D1%86%D0%B8%D0%B8-%D0%BD%D0%BE-1">Поток регистрации новых пользователей. Включает форму ввода данных, подтверждение по email и проверки по политике безопасности (например, сила пароля).</span></span></td></tr><tr><td><span id="bkmrk-reset-credentials"><span id="bkmrk-reset-credentials-1">Reset credentials</span></span></td><td><span id="bkmrk-%D0%9F%D0%BE%D1%82%D0%BE%D0%BA-%D0%B4%D0%BB%D1%8F-%D0%B2%D0%BE%D1%81%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BB"><span id="bkmrk-%D0%9F%D0%BE%D1%82%D0%BE%D0%BA-%D0%B4%D0%BB%D1%8F-%D0%B2%D0%BE%D1%81%D1%81%D1%82%D0%B0%D0%BD%D0%BE%D0%B2%D0%BB-1">Поток для восстановления доступа, если пользователь забыл пароль. Может включать подтверждение по email, OTP и другие шаги для подтверждения личности.</span></span></td></tr></tbody></table>

У каждого realm свой открытый ключ. С его помощью можно проверять подлинность полученных токенов. После авторизации под любым пользователем выполнить один раз

```python
KEYCLOAK_PUBLIC_KEY = f"""
-----BEGIN PUBLIC KEY-----
{keycloak_openid.public_key()}
-----END PUBLIC KEY-----
"""
```

<div id="bkmrk-%D0%98-%D0%B2%D1%8B%D0%B2%D0%B5%D1%81%D1%82%D0%B8-%D0%B7%D0%BD%D0%B0%D1%87%D0%B5%D0%BD%D0%B8%D0%B5.-"><div></div><div>И вывести значение. Это будет открытым ключом. </div></div>**User Federation**

Подключение внешних источников пользователей (LDAP, Active Directory или Kerberos).

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

**SAML**

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

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