Теория

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 (, ).

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