Отметим: когда у вас больше трёх микросервисов, дублирование логики проверки токенов в каждом из них превращается в головную боль. Каждый сервис дёргает базу данных или внешний 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 дней. Чтобы получить индивидуальный расчёт стоимости и сроков для вашего проекта, свяжитесь с нами. Закажите внедрение сейчас — получите консультацию бесплатно.