Коли у вас більше трьох мікросервісів, дублювання логіки перевірки токенів у кожному з них перетворюється на головний біль.
Кожен сервіс смикає базу даних або зовнішній IdP для валідації JWT — це додає 20–50 мс латентності на кожен запит і ускладнює аудит безпеки. Виникають N+1 перевірок, збільшується поверхня атаки, а відкликання токена вимагає синхронізації по всіх сервісах. Ми пропонуємо винести аутентифікацію та авторизацію на рівень API Gateway. Така API Gateway аутентифікація забезпечує єдину точку перевірки. Запит перевіряється один раз, сервіси отримують верифіковані дані через HTTP-заголовки. Такий підхід знижує затримки до п'яти разів, спрощує підтримку і дає єдину точку аудиту. Централізація скорочує витрати на інфраструктуру безпеки до 40% — середня економія для клієнтів становить $15,000 на рік. Вартість впровадження окупається за 3 місяці. JWT авторизація, OAuth2 API Gateway, та RBAC на Gateway — ключові методи централізованої аутентифікації. мікросервіси безпека — один із викликів, який вирішує Gateway. Наш досвід — більше 5 років на ринку, реалізовано понад 30 проєктів з API Gateway, обслуговуємо 20+ клієнтів. Послуга надається під ключ з гарантією 6 місяців. Отримайте аутентифікацію під ключ — зв'яжіться з нами для консультації.
Як вирішити проблему дублювання аутентифікації за допомогою API Gateway
Gateway стає єдиним шлюзом: клієнт надсилає запит, Gateway перевіряє токен (JWT/OAuth2/API Key), витягує claims і передає їх в upstream-сервіси через заголовки. Сервіси повністю довіряють Gateway і не валідують токени самостійно. Доступ напряму до сервісів блокується мережевими політиками. Централізована аутентифікація в 3 рази спрощує аудит безпеки порівняно з розподіленою схемою. API Gateway аутентифікація в 5 разів швидша за децентралізовану схему.
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 днів |
Кожен протокол має свої нюанси налаштування — розберемо їх на прикладах. OAuth2 API Gateway інтеграція дозволяє реалізувати authorization code flow.
Як налаштувати 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. JWT авторизація — один із найпоширеніших методів. Kong JWT плагін налаштовується за кілька хвилин. Детальніше див. 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 додає заголовки — сервіси отримують контекст користувача. Gateway claims передаються через заголовки. Щоб сесії не переривалися, реалізуємо автоматичне оновлення токена.
-- 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 разів і спрощує аудит. У порівнянні з дублюванням логіки, Gateway забезпечує в 5 разів менше затримок і в 3 рази простіший аудит.
Покроковий процес впровадження
- Аналіз архітектури — вивчення поточної схеми аутентифікації, визначення протоколів і 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 днів. Щоб отримати індивідуальний розрахунок вартості та термінів для вашого проєкту, зв'яжіться з нами. Замовте впровадження зараз — отримайте консультацію безкоштовно.