Создание системы аутентификации с обменом токенов Keycloak

1. Основная концепция обмена токенами

В среде архитектуры микросервисов (MSA), когда необходимо делегировать полномочия или повторно выдавать токены между несколькими сервисами, функция обмена токенами, предоставляемая Keycloak, является весьма полезным решением. Эта технология позволяет аутентифицированному клиенту передавать существующий токен, который Keycloak проверяет и обменивает на новый токен с соответствующими полномочиями и целевым адресом для назначения. Это явно определяет доверительные отношения между сервисами и контролирует объем полномочий, становясь ключевым основанием для безопасности на уровне предприятия.

2. Требования по интеграции и принятие подмены

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

Хотя мы пытались применить стандартный движок Keycloak V2, мы столкнулись с техническими ограничениями. Стандартная спецификация требует фактические учетные данные для входа (оригинальный токен) внешнего сервиса, но партнер не смог поделиться своим токеном из-за политики безопасности и мог передать только 'уникальный идентификатор пользователя (идентификатор)'.

Поскольку нам необходимо было передать только идентификационную информацию без фактического токена, внедрение стандартного движка стало невозможным. Поэтому, чтобы удовлетворить требования без разработки дополнительных пользовательских модулей, мы выбрали более старую спецификацию (V1 Прямое Наглое Подменение), которая позволила выдачу токенов только с помощью задних учетных данных и строк идентификаторов пользователей. Мы создали структуру, которая помещает 'безопасный прокси (Bridge Gateway)' перед защищением внутренней инфраструктуры и получает токены через обратный канал для доставки на экран.

3. Конфигурация Keycloak: Подключение клиентов

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

• Клиент для внешнего сервиса (Запрашивающий): Установите аутентификацию клиента в положение Включено (Конфиденциально), чтобы скрыть главный секретный ключ внутри. Чтобы применить более старый механизм V1, активируйте старую спецификацию управления полномочиями (FGAP:v1) на серверном уровне.

• Клиент для внутреннего MSA (Целевой): Активируйте обмен токенами в меню разрешений клиента, ответственного за авторизацию и экран. Создайте политику, которая позволяет только внешнему прокси-клиенту делегировать и обменивать токены.

4. Реализация на стороне сервера: Спецификация запроса токена

Прокси-сервер (Spring Boot) проверяет запросы от внешних систем и выполняет мостовой код для безопасного вызова конечной точки Keycloak. Спецификация полезной нагрузки API в соответствии с более старым стандартом V1 выглядит следующим образом.

• URL конечной точки: POST /realms/{realm-name}/protocol/openid-connect/token

• Спецификация заголовка: Content-Type: application/x-www-form-urlencoded, Authorization: Basic [Base64(ID:Secret)]

Обязательные параметры для выпуска токена

Если валидация Keycloak успешна, access_token извлекается из данных ответа. Этот токен включает только внутренние бизнес-роли пользователя (такие как ROLE_USER), и прокси загружает его в браузер пользователя после прохождения через внешний сервис и выполняет перенаправление.

5. Распространенные ошибки и решения

Это справочник по обработке трех основных ошибок выполнения, встречающихся в процессе реальной работы и развертывания.

• HTTP 404 Не найдено:Происходит, когда ссылаются на устаревший документ и включают путь /auth в адрес точки доступа. Последняя версия убрала /auth из пути контекста по умолчанию, поэтому его следует исключить.

• ошибка invalid_client:Происходит, когда опция, связанная с обменом токенов, не включена в настройках клиент-прокси, отправляющего запрос, поэтому соответствующий переключатель в консоли следует проверить снова.

• ошибка 403 Запрещено / not_allowed:Происходит, когда теряется политика доверия между клиентами. Необходимо проверить, зарегистрирован ли клиент, запрашивающий доступ, как подмножество политики в меню Разрешения целевого клиента, который является конечным пунктом назначения.

6. Ограничения устаревшего метода (V1) и практические компромиссы

Принятие устаревшей спецификации (V1 Прямое откровенное представление) вместо последнего стандарта V2 в этом проекте было осознанным архитектурным выбором для преодоления ограничений внешних интеграционных сред.

Стандартный движок Keycloak V2 требует предоставления оригинального токена для обмена как обязательной спецификации. Однако внешний партнер не смог поделиться токенами пользовательской сессии из-за своих собственных политик безопасности, и существовало техническое ограничение, которое позволяло предоставить только 'уникальный идентификатор пользователя'. В ситуации без оригинального токена единственной практической альтернативой для выполнения требования клиента 'исключить дополнительную обработку входа' своевременно, без добавления отдельной системы генерации токенов шифрования к прокси-серверу, стал старый стандарт V1, который допускает выдачу токенов только на основе идентификатора пользователя.

Потенциальные риски старой спецификации компенсировались многослойной системой защиты инфраструктурного уровня. Права сервера сети (M2M) и сети пользовательского интерфейса (UI) были строго двойным образом изолированы, а срок действия токенов, открытых в браузере, был ограничен краткосрочными токенами длительностью от 3 до 5 минут для контроля риска похищения. Хотя в будущем стоит задача миграции на стандартную систему V2 из-за обновлений в движке Keycloak, это было самым реалистичным инженерным компромиссом для достижения бизнес-целей без затрагивания интеграционных спецификаций с внешними сторонами в рамках ограниченных ресурсов.

7. Заключение

Этот проект стал повторным подтверждением того, как сложно обеспечить как безопасность, так и удобство пользователя во время B2B интеграции. Процесс пересмотра и поиска лучшей практической архитектуры в условиях внешних инфраструктурных ограничений сам по себе стал значительным активом. Я надеюсь, что этот случай интеграции послужит практической справкой для тех, кто рассматривает инфраструктуру аутентификации на основе Keycloak в среде микросервисов.

Ссылки

https://www.keycloak.org/securing-apps/token-exchange

ошуа