← назад к разделу

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

Проблема: «напишу авторизацию сам»

Когда логин делают руками, в проекте появляется примерно такой список задач:

  • хранить пароли (правильно — не сам пароль, а его хеш с солью);
  • сделать регистрацию, вход, выход, смену и сброс пароля;
  • завести роли и проверять права на каждой странице;
  • защититься от перебора паролей, угона сессии, утечки токенов;
  • позже — добавить вход через Google или второй фактор (код из приложения).

Каждый пункт по отдельности несложный. Проблема в том, что ошибка в любом из них — это дыра в безопасности, а таких пунктов десятки. И когда у вас появляется второе приложение, всё это приходится писать заново или копировать.

Keycloak — это отдельный готовый сервис, которому вы передаёте всю работу со входом. Его делает Red Hat, он бесплатный и с открытым кодом. Ваше приложение перестаёт хранить пароли и заниматься входом — оно лишь спрашивает у Keycloak: «этот человек кто, и что ему можно?»

Аналогия: раньше каждый магазин сам проверял паспорта на входе и держал свой стол охраны. Keycloak — это одна общая проходная для всех ваших зданий. Один раз показал пропуск — заходишь куда угодно в пределах доступа.

Что такое Identity Provider

Identity Provider (поставщик идентификации, сокращённо IdP) — это система, которая отвечает за один вопрос: «кто этот пользователь». Она хранит учётные записи, проверяет пароли и выдаёт приложению подтверждение «да, это действительно Иван, и вот его роли».

Keycloak — это и есть Identity Provider. Дальше работает простое разделение обязанностей:

  • Keycloak проверяет, кто пользователь, и выдаёт ему «пропуск» — токен.
  • Ваше приложение не проверяет пароль. Оно получает токен и проверяет только, что пропуск настоящий и не просрочен.

Этот «пропуск» — обычно подписанный JWT-токен: строка, внутри которой лежат имя пользователя, его роли и срок годности. Приложение убеждается, что подпись верна, и доверяет содержимому. Подробнее про устройство токена — отдельная тема, здесь важна сама идея: вход и проверка входа — это разные роли разных систем.

Что Keycloak даёт из коробки

Главная ценность — большой список готовых возможностей, которые иначе пришлось бы писать самому.

Единый вход (SSO)

Проблема: у компании пять внутренних приложений, и в каждом — свой логин. Сотрудник вводит пароль пять раз и держит в голове пять паролей.

Single Sign-On (единый вход, SSO) решает это так: пользователь входит один раз через Keycloak, а все приложения, подключённые к нему, узнают его автоматически — без повторного ввода пароля. Вышел из одного — вышел сразу из всех. Это удобно людям и проще для безопасности: учётная запись одна, и заблокировать её можно в одном месте.

OAuth2 и OpenID Connect из коробки

Это два стандартных протокола, по которым приложения и Keycloak договариваются о входе. Не нужно изобретать свой формат — Keycloak уже умеет говорить на общепринятом языке.

  • OAuth2 отвечает на вопрос «что этому пользователю можно делать» (доступ, разрешения).
  • OpenID Connect (OIDC) — это надстройка над OAuth2, которая добавляет вопрос «кто это» (вход и личность). На практике для логина используют именно OIDC.

Почему это важно: раз протоколы стандартные, к Keycloak без проблем подключаются и фронтенд на React, и мобильное приложение, и бэкенд на Spring — все они понимают OAuth2/OIDC. Вы не привязаны к одной технологии.

Управление пользователями и ролями

В Keycloak есть готовый раздел администрирования, где можно:

  • заводить и блокировать пользователей, сбрасывать им пароли;
  • создавать роли (например, customer, seller, admin) и назначать их людям;
  • объединять пользователей в группы;
  • настраивать политику паролей и второй фактор (одноразовый код).

Всё это — без единой строчки вашего кода. Роли, которые вы назначили, попадают внутрь токена, и приложение по ним решает, что пользователю разрешено.

Вход через соцсети и подключение чужих систем

Federation (федерация) — это возможность пускать в приложение пользователей, которые хранятся не в Keycloak.

  • Social login — кнопки «Войти через Google / GitHub / VK». Keycloak сам общается с этими сервисами, вам не нужно разбираться с каждым по отдельности.
  • Подключение корпоративного каталога — например, LDAP или Active Directory. Сотрудники входят под своими рабочими учётными записями, а Keycloak выступает посредником.

Снова один и тот же принцип: разнообразие источников входа Keycloak прячет за собой, а вашему приложению отдаёт один понятный токен.

Из чего состоит Keycloak

Устройство простое — всего две части.

  • Сервер Keycloak — само приложение, которое запускается отдельно (часто в контейнере). Оно показывает пользователям страницы входа, проверяет пароли и выдаёт токены. Ему нужна база данных, где хранятся учётные записи и настройки.
  • Административная консоль — веб-интерфейс для настройки. Через него заводят пользователей, роли, подключают приложения и соцсети. Это просто страницы того же сервера.

Внутри есть два понятия, которые встречаются с первых минут:

  • Realm (можно понимать как «область» или «пространство») — изолированный набор пользователей, ролей и настроек. Один realm не видит пользователей другого. Удобно, когда нужно разделить, например, сотрудников и внешних клиентов, или несколько независимых проектов на одном сервере.
  • Client (клиент) — это запись о конкретном приложении, которое подключается к Keycloak. Каждый фронтенд, бэкенд или мобильное приложение регистрируется как отдельный client внутри realm.

То есть структура такая: на сервере есть один или несколько realm, в каждом — свои пользователи и роли и список client (подключённых приложений).

Как приложение подключается к Keycloak

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

spring:
  security:
    oauth2:
      resourceserver:
        jwt:
          issuer-uri: https://keycloak.example.ru/realms/marketplace

Здесь issuer-uri — это адрес вашего realm в Keycloak. По нему Spring сам находит публичные ключи Keycloak (их набор называется JWKS) и дальше проверяет подпись каждого токена локально, не дёргая Keycloak на каждый запрос. Ключи скачиваются один раз и кешируются. Если Keycloak сменит ключ — Spring подтянет новый автоматически.

Главная мысль: подключение — это в основном настройка, а не код. Логику входа писать не нужно — её уже написали в Keycloak.

Когда Keycloak нужен, а когда избыточен

Keycloak — мощный, но не бесплатный по усилиям: это ещё один сервис, который надо запустить, обновлять и держать живым.

Keycloak оправдан, когда:

  • приложений несколько и хочется один вход на всех (SSO);
  • нужен вход через соцсети, второй фактор или подключение к корпоративному каталогу;
  • пользователей и ролей много, и ими должны управлять не программисты, а администраторы;
  • безопасность входа критична и не хочется писать её самому.

Keycloak избыточен, когда:

  • проект маленький, приложение одно, пользователей десятки;
  • вход простой и без планов на соцсети и второй фактор;
  • нет ресурсов поддерживать ещё один сервис и базу под него.

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

Коротко

  • Keycloak — отдельный готовый сервис входа (Identity Provider), забирающий у вашего приложения хранение паролей и логику авторизации.
  • Приложение не проверяет пароль — оно получает от Keycloak подписанный токен (обычно JWT) и проверяет только его подлинность.
  • Из коробки: единый вход (SSO), протоколы OAuth2/OIDC, управление пользователями и ролями, вход через соцсети и подключение корпоративных каталогов (federation).
  • OAuth2 — про «что можно», OIDC — надстройка про «кто это»; для логина используют OIDC.
  • Состоит из сервера (выдаёт токены, нужна база) и админ-консоли (настройка). Внутри: realm — изолированное пространство, client — запись о подключённом приложении.
  • Подключение — это в основном настройка (issuer-uri на realm), а не код; токены проверяются локально по ключам JWKS.
  • Keycloak оправдан при нескольких приложениях, соцсетях, втором факторе, многих ролях; для маленького проекта с одним простым входом он избыточен.