Keycloak не заканчивается на форме входа

https://www.youtube-nocookie.com/embed/uq2I9z_ZB6Q

Автор: Eugene Suleimanov · Proselyte

---

Почти двухчасовой курс от автора Eugene Suleimanov показывает Keycloak не как «готовую страницу входа», а как отдельную платформу, которой приложение передаёт значительную часть работы с аутентификацией и авторизацией.

Полностью пересказать такой материал в одном дайджесте невозможно. Автор последовательно проходит от realm, clients, scopes и roles до OAuth 2.0, OpenID Connect, SAML, федерации пользователей и межсервисного доступа. Затем собирает практическую систему с двумя приложениями, PostgreSQL и Keycloak, подключает внешние Identity Providers и защищает вызовы между сервисами.

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

Кому смотреть: разработчикам и архитекторам, которые выбирают между собственной подсистемой доступа и отдельной identity-платформой.

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

---

Курс начинается с основных сущностей Keycloak. Realm изолирует пользователей и настройки, client представляет приложение, client scopes управляют набором запрашиваемых данных, а roles используются при принятии решений о доступе. Это уже больше, чем внешний вид формы входа: Keycloak становится источником правил и токенов для нескольких приложений.

Отдельный блок посвящён OAuth 2.0 и OpenID Connect. Это полезное разделение: OAuth прежде всего описывает делегирование доступа, а OpenID Connect добавляет идентификацию пользователя. Автор рассматривает Authorization Code Flow, PKCE, Client Credentials, Device Code и Refresh Token Flow, а также объясняет, для каких участников они предназначены.

Дальше Keycloak связывает разные системы идентификации. GitHub и Auth0 подключаются как внешние Identity Providers. LDAP и Kerberos показаны как источники пользователей через user federation. В обоих случаях приложению не нужно самостоятельно поддерживать отдельный протокол для каждого провайдера.

Практическая часть заканчивается межсервисным взаимодействием. Сначала один сервис обращается к другому без защиты, затем вызов переводится на Client Credentials и JWT с ролями.

Keycloak не избавляет команду от необходимости проектировать доступ. Он переносит эту работу в отдельную платформу, поэтому ошибки в realm, redirects, scopes и roles способны затронуть сразу несколько приложений. Ценность курса в том, что он показывает не только возможности такого центра, но и его масштаб.