Теория

https://www.youtube.com/watch?v=uq2I9z_ZB6Q

Функциональность:

Single-sign on, Single-sign out для браузерных приложений
Поддержка OpenID/OAuth 2.0/SAML
Identity Brokering - аутентификация с помощью внешних провайдеров, Social login
User federation - синхронизация с LDAP / Active directory / Kerberos
Консоль администратора

Для деления на блоки используются Realm. Каждый Realm изолирован от остальных. В нем хранится конфигурация, набор приложений и пользователи. Master realm администрирование системы.

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

Роли (realm roles)

Каждая роль может быть переключена в композитный режим (объединение других ролей).

Название	Композитная	Назначение
admin	Да	включает административные права - может управлять пользователями, клиентами, ролями и конфигурацией реалма
create-realm	Нет	позволяет пользователю создавать новые realms через Admin Console или REST API (только в master realm).
default-roles-master	Да	набор ролей, назначаемых по умолчанию всем новым пользователям master realm. Включает offline_access, uma_authorization и другие (можно посмотреть внутри composite).
offline-access	Нет	дает возможность получать offline refresh tokens - живут дольше, не требуют активной сессии пользователя.
uma_authorization	Нет	позволяет использовать User-Managed Access (UMA) - механизм, при котором пользователь может делегировать доступ к своим ресурсам другим пользователям (используется при ресурсно-ориентированном доступе).

Консоль управления сервером

Доступ: ip_keycloak:8080/admin

Группы (организационная принадлежность) и роли (набор разрешений). Когда пользователь добавляется в группу, он наследует все роли. Единственная задача keycloak: Пользователь - Разрешение. Внутри роли сопоставляется разрешение. Группа упрощает управление пользователями.

Регистрация приложения. Чтобы приложение могло использовать ресурсы keycloak, оно должно быть зарегистрировано. Клиенты (Clients) - это сущности, которые могут отправлять запрос в Keycloak на аутентификацию пользователя. Раздел Clients. Клиенты делятся по идентификаторам.

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

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

Встроенные сервисы

Управление аккаунтом (пользователь) В списке клиентов отображается как clients-account.

Доступ: ip_keycloak:8080/realms/<realm_name>/account

Фронтенд управления аккаунтом (пользователь) В списке клиентов отображается как clients-account-console.

Взаимодействие с Keycloak через CLI или REST API. В списке клиентов отображается как clients-admin-cli. Типичный use-case: получение токена через kcadm.sh или curl для скриптов/CI/CD. Поддерживает client_credentials и password гранты. Пример:

Отправим post запрос с параметрами username, password, grant_type=password, client-id=admin-cli по адресу 
http://.../realms/master/protocol/openid-connect/token

Ответом придет access_token который добавляется в Header запроса, 
поле Authorization значение Brearer <значение token>

теперь можно использовать API для работы.

Клиент для федерации идентичности (SSO между провайдерами). В списке клиентов отображается как Clients - broker. Пример: Keycloak как Identity Broker между Google, GitHub и другим Keycloak сервером.

Клиент для административной консоли Keycloak. В списке клиентов отображается как security-admin-console. Доступ: /admin/{realm}/console Используется: при входе в админ-панель, управлении реалмами, пользователями и клиентами.

Области видимости клиентов (client scopes)

Механизм, определяющий, какие данные и разрешения получит клиент в access token / ID token при аутентификации пользователя. По-другому это способ контролировать, что именно получит клиент при запросе авторизации у пользователя. Типы assigned type:

Default Этот scope всегда включается в токен по умолчанию, даже если клиент не запрашивает его явно.
Optional Scope будет применён только если клиент его запросит в параметре scope=... при авторизации.
(Unassigned) Scope не применяется клиенту вообще, пока его не назначат вручную или не укажут явно в токене.

Стандартные scopes:

Название	Тип	Протокол	Назначение
acr	Default	OpenID Connect	добавляет в токен acr (Authentication Context Class Reference) - уровень аутентификации (например, MFA, пароль и т. д.).
address	Optional	OpenID Connect	добавляет адрес пользователя (address claim) в токен (если заполнено в профиле).
basic	Default	OpenID Connect	включает базовые claims - sub, name, preferred_username, given_name, family_name
e-mail	Default	OpenID Connect	добавляет email и email_verified claims в ID и Access токены
microprofile-jwt	Optional	OpenID Connect	обеспечивает совместимость с Eclipse MicroProfile JWT - популярным стандартом для Java microservices
offline_access	Optional	OpenID Connect	разрешает выдачу offline refresh token (живёт долго и используется без пользовательского взаимодействия).
role_list	Default	SAML	включает список ролей (roles) пользователя в SAML assertions
roles	Default	OpenID Connect	добавляет роли пользователя (realm roles и client roles) в access token (в realm_access.roles и resource_access)

Также есть phone, profile

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

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 (Client Credentials, Device Code, Refresh Token).

Название	Описание	Тип приложения
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).

User Federation

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

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