Отметим: когда у вас больше трёх микросервисов, дублирование логики проверки токенов в каждом из них превращается в головную боль. Каждый сервис дёргает базу данных или внешний IdP для валидации JWT — это добавляет 20–50 мс латентности на каждый запрос и усложняет аудит безопасности. Возникают N+1 проверок, увеличивается поверхность атаки, а отзыв токена требует синхронизации по всем сервисам. Мы предлагаем вынести аутентификацию и авторизацию на уровень API Gateway. Запрос проверяется один раз, сервисы получают верифицированные данные через HTTP-заголовки. Такой подход снижает задержки до пяти раз, упрощает поддержку и даёт единую точку аудита. Снижает затраты на инфраструктуру безопасности до 40% за счёт централизации. Средняя экономия на операционных расходах составляет 35%. Наш опыт — более 5 лет, реализовано свыше 30 проектов с API Gateway. Услуга предоставляется под ключ с гарантией 6 месяцев. Получите аутентификацию под ключ — свяжитесь с нами для консультации.
Как API Gateway решает проблему дублирования аутентификации?
Gateway становится единым шлюзом: клиент отправляет запрос, Gateway проверяет токен (JWT/OAuth2/API Key), извлекает claims и передаёт их в upstream-сервисы через заголовки. Сервисы полностью доверяют Gateway и не валидируют токены самостоятельно. Доступ напрямую к сервисам блокируется сетевыми политиками. Централизованная аутентификация в 3 раза упрощает аудит безопасности по сравнению с распределённой схемой.
Client → [API Gateway: validate JWT, extract claims] → Service ↑ X-User-ID, X-Role, X-Tenant headers Принцип работы
Для каждого запроса Gateway выполняет: валидацию подписи и срока действия токена, извлечение claims, проверку прав доступа (ACL), прокидывание заголовков в upstream. Время проверки — менее 5 мс.
Какие протоколы аутентификации поддерживаются?
Мы настраиваем все популярные схемы. Сравнение времени внедрения:
| Протокол | Сценарий | Время внедрения |
|---|---|---|
| JWT (RS256/HS256) | Внутренние API, мобильные | 2–3 дня |
| OAuth2 (authorization code) | Внешние клиенты, интеграции | 3–4 дня |
| OIDC | Single Sign-On, корпоративные | 3–5 дней |
| mTLS | Service-to-service, B2B | 4–5 дней |
Каждый протокол имеет свои нюансы настройки — разберём их на примерах.
JWT-валидация в Kong
Пример настройки JWT плагина в Kong
Настройка базовой JWT-валидации в Kong занимает несколько минут:
# Включить JWT плагин curl -X POST http://localhost:8001/plugins \ -d "name=jwt" # Создать consumer и credentials curl -X POST http://localhost:8001/consumers \ -d "username=frontend-app" curl -X POST http://localhost:8001/consumers/frontend-app/jwt \ -d "algorithm=RS256" \ -d "rsa_public_key=$(cat /keys/public.pem)" Клиент передаёт Authorization: Bearer <JWT>. Kong проверяет подпись и срок действия — при ошибке возвращает 401. Подробнее см. Kong JWT plugin.
OIDC в APISIX с Keycloak
Для интеграции с Keycloak используем плагин openid-connect:
{ "plugins": { "openid-connect": { "client_id": "api-gateway", "client_secret": "secret", "discovery": "https://keycloak.company.com/realms/myapp/.well-known/openid-configuration", "scope": "openid profile", "token_signing_alg_values_expected": ["RS256"], "set_access_token_header": true, "set_userinfo_header": true } } } После настройки Gateway автоматически проверяет ID-токен и передаёт userinfo в upstream.
Как настроить RBAC и Lambda Authorizer?
Для ограничения доступа к эндпоинтам по ролям используем RBAC, а для сложной логики — кастомные авторизаторы.
Настройка RBAC на Gateway
В Kong RBAC реализуется через ACL-плагин. Создаём группы и назначаем consumer'ов:
# ACL плагин для сервиса admin-api curl -X POST http://localhost:8001/services/admin-api/plugins \ -d "name=acl" \ -d "config.allow[]=admin-group" \ -d "config.hide_groups_header=true" # Назначить consumer alice в группу admin-group curl -X POST http://localhost:8001/consumers/alice/acl \ -d "group=admin-group" Кастомный Lambda Authorizer
Для ресурсов с гибкими правами (например, tenant-based доступ) используем AWS Lambda Authorizer. Он получает JWT, извлекает claims и возвращает IAM-политику с контекстом.
Как передаются claims и обрабатывается refresh token?
После валидации Gateway добавляет заголовки — сервисы получают контекст пользователя. Чтобы сессии не прерывались, реализуем автоматическое обновление токена.
-- Kong plugin: извлечение claims из JWT local jwt_decoder = require "kong.plugins.jwt.jwt_parser" local function execute(conf) local token = kong.request.get_header("authorization") if token then token = token:gsub("Bearer ", "") local jwt_obj = jwt_decoder:new(token) local claims = jwt_obj.claims kong.service.request.set_header("X-User-ID", claims.sub) kong.service.request.set_header("X-Tenant-ID", claims.tenant_id) kong.service.request.set_header("X-User-Role", claims.role) end end Сравнение производительности: с Gateway и без
| Сценарий | Средняя задержка запроса | Количество проверок токена | Аудит безопасности |
|---|---|---|---|
| Без Gateway | 20–50 мс на сервис | N+1 (каждый сервис) | Сложный, распределённый |
| С Gateway | 5–10 мс (одна проверка) | 1 | Единая точка |
Gateway снижает задержки в 2–5 раз и упрощает аудит.
Пошаговый процесс внедрения
- Анализ архитектуры — изучение текущей схемы аутентификации, определение протоколов и IdP.
- Выбор Gateway — подбор решения (Kong, APISIX, AWS API Gateway, Traefik, Nginx) под нагрузку и бюджет.
- Настройка аутентификации — подключение JWT/OAuth2/OIDC/mTLS, интеграция с IdP (Keycloak, Auth0, Okta).
- Реализация авторизации — настройка RBAC/ABAC, кастомные политики через Lambda Authorizer.
- Тестирование и деплой — проверка сценариев (время жизни токена, refresh, отзыв) и запуск в стейджинг/продакшен.
Что входит в работы по внедрению?
- Анализ текущей архитектуры и выбор схемы (JWT/OAuth2/OIDC/mTLS).
- Настройка Gateway (Kong, APISIX, AWS API Gateway, Traefik, Nginx).
- Интеграция с Identity Provider (Keycloak, Auth0, Okta, собственный IdP).
- Прокидывание claims в заголовки, реализация RBAC/ABAC.
- Написание кастомного Lambda Authorizer при необходимости.
- Документация для разработчиков и обучение команды.
- Поддержка 2 недели после сдачи.
Сроки выполнения
Базовая JWT/OIDC аутентификация с RBAC — от 2 до 3 рабочих дней. С кастомным Lambda Authorizer и mTLS — до 5 дней. Чтобы получить индивидуальный расчёт стоимости и сроков для вашего проекта, свяжитесь с нами. Закажите внедрение сейчас — получите консультацию бесплатно.