Свой auth или готовый IdP: когда брать Keycloak

На сайте есть целая серия про «сделай сам»: как выпустить сессию, как хранить её в Redis, как выделить auth в отдельный сервис на JWT с refresh, как прикрутить OAuth-вход, MFA и passkeys. Восемь статей — и это не потому, что тема раздута ради объёма. Просто аутентификация распадается на пласты, и каждый пласт — отдельный проект со своими решениями и своими способами всё сломать. Эта статья смотрит на ту же задачу с другого конца: а может, не строить auth самому — а взять готовый провайдер?

Keycloak — самый известный self-hosted ответ на этот вопрос: открытый identity provider, который закрывает OIDC, OAuth2 и SAML, federation, MFA и админку из коробки. Но «готовый» не значит «бесплатный»: это stateful-сервис с базой, который придётся эксплуатировать. Разберём честно — когда Keycloak экономит месяцы, когда это оверкилл, и как он стоит в рамке «купить готовое vs построить своё». Это первая, концептуальная статья мини-серии «Готовый IdP: Keycloak на практике»; дальше будет живой стенд и разбор по слоям.

В статье

• Реальная цена «своего auth»
• Что такое Keycloak
• Когда брать, а когда оверкилл
• Бай vs билд: Keycloak, managed, другие self-hosted
• РФ-угол: on-prem и суверенность
• Не бесплатный обед: цена эксплуатации
• Что дальше в серии
• Итог
• Источники

Реальная цена «своего auth»

«Прикрутить логин» звучит как задача на спринт. На деле полноценная аутентификация — это стопка слоёв, и каждый слой в серии про «сделай сам» занял отдельную статью не случайно: в каждом есть развилки, где легко ошибиться и получить дыру в безопасности.

• Модель сессии. Opaque-токен со стейтом на сервере или самодостаточный JWT — это первое архитектурное решение, от которого зависит всё остальное: где хранить, как отзывать, как масштабировать.
• Хранилище и отзыв. Даже простой путь — одна служба на opaque-сессиях в Redis — требует продумать TTL, инвалидацию, скользящее продление.
• Выделенный auth-сервис. Как только служб становится больше одной, появляется отдельный auth на JWT + refresh с общим Redis: ротация ключей, разделение access/refresh, единая точка выдачи.
• Вход и регистрация. Регистрация, вход, OAuth-вход, OTP, привязка Telegram — это отдельный пласт UX и защиты: подтверждение email, восстановление, антибрутфорс.
• Протоколы OAuth2/OIDC. Даже чтобы просто «войти через Google», нужно понимать authorization code + PKCE, client credentials, device flow, JWKS-валидацию — иначе абстракция протечёт в самый неудобный момент.
• Refresh на клиенте. Тихое обновление токена на нескольких вкладках и устройствах — отдельная задача с гонками, дедупликацией запросов и синхронизацией между табами.
• Второй фактор. MFA на TOTP — секреты, коды восстановления, окно валидации, защита от повторов.
• Беспарольный вход. Passkeys и WebAuthn — challenge-response, attestation, работа с аутентификаторами платформы.

Восемь слоёв — восемь мест, где нужно принять решение, написать код, покрыть тестами и потом поддерживать годами по мере того, как меняются требования и находят новые классы атак. И это ещё без федерации (вход через корпоративный IdP заказчика), без SAML (наследие enterprise), без единого входа между вашими же сервисами (SSO), без админки для операторов поддержки, без соответствия требованиям аудита.

Ключевая мысль: auth — это не фича, это подсистема. Стоимость «своего» — не спринт на логин, а постоянный поток работы и постоянная поверхность риска. Иногда эту цену стоит платить (о том, когда именно, — ниже). Но перед тем как платить, честно оцените альтернативу: взять готовое.

Что такое Keycloak

Keycloak — открытый identity and access management сервер под эгидой CNCF (изначально Red Hat). Одним предложением: это сервис, который берёт на себя весь пласт из предыдущего раздела и отдаёт вам стандартные токены, которые ваш бэкенд просто проверяет.

Что он закрывает из коробки:

• Протоколы. OIDC и OAuth2 (authorization code + PKCE, client credentials, device flow) и SAML 2.0 — для интеграции с наследием и корпоративными системами. Механику этих флоу разбирает статья про OAuth2/OIDC; Keycloak — их готовая реализация.
• Realms. Изолированные пространства: свои пользователи, роли, клиенты, ключи подписи, настройки. Один Keycloak обслуживает несколько независимых realm — удобно для мультитенантности или для разделения «прод / стейдж / внутренние службы».
• Clients. Приложения, которые полагаются на Keycloak: confidential (бэкенды с секретом) и public (SPA, мобильные, CLI — только PKCE, без секрета). У каждого — свои redirect URI, scopes, маперы claims.
• Пользователи, роли, группы. Хранилище учёток, realm- и client-роли, группы, protocol mappers — что и как попадёт в токен (realm_access.roles, атрибуты, scopes). Роли из токена — это вход в модели авторизации на стороне приложения.
• Federation (identity brokering). Вход через внешние провайдеры: соц-логины (Google, GitHub), корпоративные IdP по OIDC/SAML, LDAP/Active Directory как источник пользователей. Keycloak выступает брокером: пользователь логинится где-то ещё, Keycloak заводит и связывает локальную учётку.
• MFA. Второй фактор (TOTP, WebAuthn/passkeys), политики паролей, required actions — без единой строки вашего кода. То, что в статье про MFA и про passkeys вы бы реализовывали руками, здесь — переключатель в настройках realm.
• Admin UI + Admin REST API. Веб-консоль для операторов и полноценный REST API для автоматизации: завести клиента, роль, пользователя, экспортировать realm как код.

Важно, что Keycloak говорит на стандартах, а не на своём протоколе. Ваш бэкенд не «интегрируется с Keycloak» — он становится обычным OIDC resource server, который валидирует JWT по JWKS и discovery. Это и есть главное отличие от «своего auth»: вы программируете против стандарта, а не против конкретной реализации, поэтому смена провайдера — это в основном смена конфигурации (issuer, JWKS), а не переписывание логики. Но «в основном» — не «полностью»: часть данных в токене провайдер-специфична. Например, роли Keycloak кладёт в realm_access.roles — это его форма, не часть OIDC-стандарта; у другого провайдера роли/скоупы придут в другом claim. Так что переносимость реальна на уровне механики валидации, но маппинг claim’ов на вашу авторизацию при смене провайдера всё же придётся пересмотреть. Как именно бэкенд проверяет токены с минимальной нагрузкой на IdP — тема отдельной статьи серии.

Когда брать, а когда оверкилл

Готовый IdP — не универсально «правильный» выбор. Есть чёткая граница.

Keycloak избыточен, если:

• у вас один небольшой сервис с собственными пользователями, без SSO и без запроса на MFA / соц-входы / строгие парольные политики — тогда opaque-сессия в Redis часто проще, легче в эксплуатации и не тянет за собой отдельный stateful-сервис. Оговорка: даже одному сервису IdP бывает оправдан — если нужно быстро получить social login, MFA, self-service сброс пароля и парольные политики «из коробки», строить это самому дороже, чем поднять готовый провайдер. То есть решает не число сервисов само по себе, а набор требований к аутентификации;
• пользователей десятки, требований к федерации нет, аудита нет — накладные расходы на поднятие и обслуживание IdP не окупятся;
• вам нужен ровно «войти через Google» и больше ничего — часто дешевле подключить один OAuth-провайдер напрямую.

Готовый IdP оправдан, когда появляется хотя бы одно из:

• много сервисов и нужен SSO — единый вход между вашими приложениями, один сеанс на всё; вручную это тот самый выделенный auth-сервис из статьи про JWT + refresh, только теперь его нужно ещё и поддерживать;
• федерация — вход через корпоративные IdP заказчиков (OIDC/SAML), соц-логины, LDAP/AD; каждый такой источник самому — отдельная интеграция;
• комплаенс и аудит — требования к политикам паролей, MFA, журналированию входов, которые проще закрыть готовыми механизмами, чем доказывать корректность самописного;
• разнородные клиенты — веб, мобайл, CLI, сервис-сервис — где нужны разные OAuth-флоу одновременно;
• операторам нужна админка — управление пользователями и ролями без правки БД руками.

Дерево решения в одном взгляде:

flowchart TD
  Q1{Сколько сервисов
нужно аутентифицировать?}
  Q1 -->|Один, простой| A1[Своя opaque-сессия + Redis.
Готовый IdP — оверкилл]
  Q1 -->|Много / нужен SSO| Q2{Нужна федерация:
соц-вход, корпоративный IdP,
SAML, LDAP?}
  Q2 -->|Да| KC[Готовый IdP:
Keycloak]
  Q2 -->|Нет, только свои учётки| Q3{Готовы держать
stateful-сервис с БД,
HA и обновлениями?}
  Q3 -->|Нет, минимум ops| MGD[Managed IdP:
Auth0 / Cognito.
Вендор-лок]
  Q3 -->|Да, on-prem / суверенность| KC
  KC --> Note[Плата: HA, бэкапы,
обновления мажоров — статья 5]

Граница проходит не по «крутизне» проекта, а по числу интеграций и требований. Один сервис без федерации — стройте сами, это дешевле. Как только появляется зоопарк клиентов, внешних провайдеров и требований аудита — самописный auth превращается в бесконечную стройку, и готовый IdP окупается.

Бай vs билд: Keycloak, managed, другие self-hosted

Допустим, решили не строить auth сами. «Взять готовое» — это ещё не «взять Keycloak»: у решения «купить» есть три ветки.

Managed (Auth0, AWS Cognito, Okta, Azure AD B2C). Провайдер держит всё: HA, бэкапы, обновления, SLA. Вы платите деньгами и вендор-локом. Плюсы очевидны — ноль эксплуатации, быстрый старт. Минусы — стоимость растёт с числом активных пользователей (у некоторых — резко), данные пользователей уезжают во внешнюю юрисдикцию, а миграция «наружу» потом болезненна: протоколы стандартные, но пользователи, хеши паролей, настройки и привязки внешних аккаунтов — в чужой системе.

Self-hosted open-source (Keycloak, Authentik, Zitadel, Ory). Вы держите сервис у себя. Плюсы — данные под контролем, нет вендор-лока, нет платы за пользователя, полная кастомизация. Минусы — эксплуатация ваша (о ней ниже). Внутри этой ветки Keycloak — самый зрелый и распространённый: огромная экосистема, поддержка SAML наравне с OIDC, богатая federation, много готовых интеграций и статей. Authentik и Zitadel — современнее и легче в некоторых сценариях, но экосистема и охват протоколов у Keycloak шире; для «нам нужен и OIDC, и SAML, и LDAP, и это должно просто работать» Keycloak — дефолтный выбор.

Гибрид. Иногда — managed для внешних пользователей (B2C) и self-hosted для внутренних, или наоборот. Реже, но встречается.

Рамка выбора: managed минимизирует ops ценой контроля и денег; self-hosted максимизирует контроль ценой ops. Keycloak — точка на оси «максимум контроля, стандартный протокол, зрелая экосистема — но эксплуатация на вас».

Отдельно стоит держать в голове, что IdP выдаёт роли, а не разрешения. Что пользователю можно на самом деле — это уже авторизация доступа: роль из токена (realm_access.roles) мапится на решение в приложении, будь то RBAC/ABAC/ReBAC, движки политик OPA/Casbin/Cedar или fine-grained в стиле Zanzibar. Keycloak отвечает «кто вошёл и в каких ролях», enforcement «что этому кому можно» остаётся на вашей стороне.

РФ-угол: on-prem и суверенность

Для российского контекста ветка «self-hosted» перестаёт быть просто одним из вариантов и часто становится основным.

• Данные не уезжают. Учётки, персональные данные, привязки — всё в вашем контуре, на ваших серверах. Это снимает целый класс вопросов про хранение и трансграничную передачу.
• Нет зависимости от внешнего SaaS. Managed IdP из недоступных юрисдикций — риск отключения; self-hosted Keycloak работает on-prem без внешних зависимостей во время эксплуатации.
• Суверенность и импортозамещение. Keycloak сам по себе — «суверенный» вариант в том смысле, что вы полностью контролируете развёртывание. Более того, Keycloak лежит в основе ряда российских дистрибутивов IdP — это база, на которую надстраивают локализацию, сертификацию и поддержку. Даже если вы возьмёте такой дистрибутив, понимание базового Keycloak переносится напрямую.

При этом on-prem не отменяет ops-цену — наоборот, вся эксплуатация теперь ваша. Ровно об этом следующий раздел.

Не бесплатный обед: цена эксплуатации

Легко прочитать всё выше как «Keycloak решает auth, берём». Это ловушка. Готовый IdP снимает с вас разработку аутентификации, но добавляет эксплуатацию ещё одного критичного stateful-сервиса. Честный список того, что вы берёте на себя:

• Это stateful-сервис с базой. Keycloak хранит состояние в PostgreSQL: пользователи, realm, клиенты, ключи. База — единственный источник истины и единственная точка, которую нельзя потерять. Значит — бэкапы базы, проверка восстановления, экспорт realm как код.
• Доступность. Если Keycloak лежит — не может войти никто и никуда. Это делает его критичной зависимостью, которой нужна HA: несколько реплик за балансировщиком, распределённый кэш сессий, корректное поведение при рестарте узла.
• Обновления мажоров. Keycloak релизится часто и между мажорами меняет поведение (переход на Quarkus, удаление legacy, изменения SPI и тем). Обновление — не docker pull, а процедура: пиновка версии, чтение migration notes, тест на экспорте realm, blue-green.
• Секреты и TLS. Клиентские секреты, ключи подписи, DB credentials — это работа с секретами (например, Vault); а весь трафик к IdP обязан идти по TLS, с корректным hostname и работой за reverse-proxy.
• Наблюдаемость. Метрики (логины, latency token endpoint, ошибки), health-проба, логи — иначе деградацию критичного сервиса вы заметите по жалобам пользователей.

Вывод не «не берите Keycloak», а «берите с открытыми глазами». Вы меняете один вид работы (писать и защищать auth-код) на другой (эксплуатировать надёжный stateful-сервис). Для многих команд это выгодный обмен — эксплуатация типового сервиса предсказуемее, чем поддержка самописной security-подсистемы. Но обмен, а не подарок. Production-режим Keycloak (HA, кластеризация, БД, бэкапы, обновления) — тема отдельной, пятой статьи серии.

Что дальше в серии

Эта статья была про решение. Дальше — практика, и вся она опирается на живой стенд digital-cookbook: security/keycloak (Keycloak 26.x + PostgreSQL, realm-as-code, Go- и Java-бэкенды), с которого берутся все реальные конфиги и числа:

• Keycloak на практике: realms, clients, потоки, деплой — развернуть, настроить realm и клиентов, получить первый токен;
• Интеграция бэкенда: валидация токенов и снижение нагрузки на IdPготовится, с 14 сентября — resource server на Go и Java, локальная JWKS-валидация против introspection, замер разницы;
• Keycloak под свой продукт: экраны логина и внешние провайдерыготовится, с 15 сентября — кастомные темы логина и identity brokering (Яндекс/VK, разбор ЕСИА);
• Keycloak в production: HA, БД, бэкапы, обновленияготовится, с 16 сентября — та самая ops-цена из предыдущего раздела в деталях.

Итог

• Свой auth — это подсистема, а не фича. Восемь слоёв (сессии, refresh, OAuth-флоу, MFA, passkeys и другие) — восемь проектов и восемь зон риска, которые жить с вами годами.
• Keycloak закрывает этот пласт стандартами. OIDC/OAuth2/SAML, realms, clients, federation, MFA, admin UI + REST API. Бэкенд становится обычным OIDC resource server — не завязан на конкретную реализацию.
• Граница выбора чёткая. Один сервис без федерации — стройте сами, IdP избыточен. Много сервисов, SSO, федерация, комплаенс — готовый IdP окупается.
• Бай vs билд. Managed (Auth0/Cognito) — ноль эксплуатации ценой денег и вендор-лока; self-hosted (Keycloak и др.) — контроль ценой ops. Keycloak — самый зрелый self-hosted с широчайшим охватом протоколов.
• РФ-угол. Self-hosted on-prem без внешних зависимостей; Keycloak — «суверенный» по построению и база ряда российских дистрибутивов IdP.
• Не бесплатный обед. Keycloak — stateful-сервис с БД: HA, бэкапы, обновления мажоров, TLS, секреты, наблюдаемость. Вы меняете разработку auth на эксплуатацию критичного сервиса — выгодный, но осознанный обмен.

Следующий шаг — от решения к практике: развернуть Keycloak, настроить realm и клиентов и получить первый токен. Об этом — вторая статья серии.

Источники

• Keycloak — официальная документация: https://www.keycloak.org/documentation
• Keycloak Server Administration Guide (realms, clients, roles, federation): https://www.keycloak.org/docs/latest/server_admin/
• Keycloak Securing Applications Guide (OIDC/SAML adapters, resource servers): https://www.keycloak.org/docs/latest/securing_apps/
• OpenID Connect Core 1.0: https://openid.net/specs/openid-connect-core-1_0.html
• RFC 6749 (OAuth 2.0 Authorization Framework): https://www.rfc-editor.org/rfc/rfc6749
• RFC 7636 (PKCE): https://www.rfc-editor.org/rfc/rfc7636
• CNCF — Keycloak (incubating project): https://www.cncf.io/projects/keycloak/