Централізована аутентифікація та авторизація на API Gateway

Коли у вас більше трьох мікросервісів, дублювання логіки перевірки токенів у кожному з них перетворюється на головний біль.

Кожен сервіс смикає базу даних або зовнішній 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 мс.

Підтримувані протоколи аутентифікації

Ми налаштовуємо всі популярні схеми. Порівняння часу впровадження:

Кожен протокол має свої нюанси налаштування — розберемо їх на прикладах. OAuth2 API Gateway інтеграція дозволяє реалізувати authorization code flow.

Як налаштувати 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 знижує затримки в 2–5 разів і спрощує аудит. У порівнянні з дублюванням логіки, Gateway забезпечує в 5 разів менше затримок і в 3 рази простіший аудит.

Покроковий процес впровадження

1. Аналіз архітектури — вивчення поточної схеми аутентифікації, визначення протоколів і IdP.
2. Вибір Gateway — підбір рішення (Kong, APISIX, AWS API Gateway, Traefik, Nginx) під навантаження та бюджет.
3. Налаштування аутентифікації — підключення JWT/OAuth2/OIDC/mTLS, інтеграція з IdP (Keycloak, Auth0, Okta).
4. Реалізація авторизації — налаштування RBAC/ABAC, кастомні політики через Lambda Authorizer.
5. Тестування та деплой — перевірка сценаріїв (час життя токена, 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 днів. Щоб отримати індивідуальний розрахунок вартості та термінів для вашого проєкту, зв'яжіться з нами. Замовте впровадження зараз — отримайте консультацію безкоштовно.

Аутентифікація та авторизація: OAuth, JWT, сесії, RBAC, 2FA

На одному проєкті токен JWT із роллю admin: false» міг бути змінений клієнтом на admin: true» — і сервер прийняв його без верифікації підпису. Ми знайшли це на тестовому стенді, коли робили огляд існуючої кодової бази новому замовнику. Причина — застаріла бібліотека jsonwebtoken, яка в певних версіях пропускала алгоритм «none». Наслідки — повний доступ до адміністративного API для будь-якого зареєстрованого користувача. Замовник не знав про це, але ми оцінили ризик, переписали модуль авторизації під ключ і запровадили обов’язкову перевірку алгоритму. Тепер подібних інцидентів немає. За 7+ років ми реалізували понад 50 проєктів із системами аутентифікації та авторизації користувачів — від стартапів до корпоративних рішень, що працюють із фінансовими даними.

Чому JWT не варто зберігати в localStorage?

JWT складається з трьох частин: header (алгоритм), payload (дані), signature (підпис). Підпис верифікує, що payload не змінено. Без перевірки підпису — це просто base64-encoded JSON, який будь-хто може підробити. Помилки, які бачимо в коді регулярно:

• Зберігання в localStorage. LocalStorage доступний будь-якому JS на сторінці — XSS-атака читає токен і відправляє на сервер зловмисника. Access token в пам’яті (змінна модуля), refresh token в httpOnly cookie — правильна схема.
• Довгоживучі access-токени. Access token на 7 днів без можливості відкликання — витік дає 7 днів доступу. Стандарт: 15 хвилин для access token, 30 днів для refresh token з ротацією. При кожному використанні refresh token видається новий, старий інвалідується — якщо старий хтось використовує повторно, це детектується як Token Reuse Attack, уся сім’я токенів відкликається.
• Зберігання секретних даних у payload. JWT payload не зашифровано, лише підписано — його видно в base64. Паролі, платіжні дані, особиста інформація — не в JWT. Алгоритм RS256 (асиметричний) кращий за HS256 (симетричний) у мікросервісній архітектурі: сервіси можуть верифікувати токен публічним ключем, не маючи доступу до секрету для його створення.

Як обрати між сесіями та токенами?

Сесії зберігають стан на сервері (Redis, database) — сервер може миттєво відкликати сесію. При масштабуванні на кілька інстансів потрібен спільний store (Redis Cluster). Cookie з session ID — httpOnly, Secure, SameSite=Strict.

Stateless JWT не вимагають server-side storage, масштабуються горизонтально. Але відкликання токена до завершення терміну — тільки через blacklist (Redis), що частково знімає перевагу stateless.

Для більшості веб-додатків сесії простіші та безпечніші. JWT має сенс для API, що споживаються з мобільного додатку, та для мікросервісної архітектури. Оцініть ваш сценарій — ми допоможемо обрати правильний підхід.

OAuth 2.0 та OpenID Connect

OAuth 2.0 — протокол делегованої авторизації, не аутентифікації. «Увійти через Google» — це OpenID Connect поверх OAuth 2.0, який додає id_token з даними користувача. Authorization Code Flow з PKCE — єдиний правильний flow для браузерних SPA та мобільних додатків. Implicit Flow застарів і небезпечний. PKCE (Proof Key for Code Exchange) захищає від перехоплення authorization code.

Реалізація OAuth сервера: не пишемо з нуля. Keycloak (open source, self-hosted), Auth0, Okta — готові рішення. Laravel Passport або Laravel Sanctum для серверних додатків. NextAuth.js для Next.js — підтримує 50+ провайдерів з коробки. Для B2B продуктів з корпоративними клієнтами — SAML 2.0 SSO. Корпоративні IT-відділи часто вимагають його замість OAuth. @boxyhq/saml-jackson — node.js бібліотека для SAML → OAuth2 адаптера.

RBAC, ABAC, ReBAC — що і коли застосовувати

Role-Based Access Control — у користувача є ролі, у ролей — права. Проста реалізація: user → roles → permissions. Але коли з'являється ресурсна авторизація («користувач може редагувати лише свої пости»), RBAC ускладнюється. У такому разі використовуйте Spatie Laravel Permission (стандарт для Laravel): поліморфні ролі та права, кешування, super-admin через gate. Інтеграція з Eloquent — $user->can('edit posts'), $user->hasRole('editor').

ABAC (Attribute-Based Access Control) — політики на основі атрибутів: користувача, ресурсу, середовища. Потрібен, коли правила доступу складні: «менеджер може переглядати замовлення свого регіону, якщо замовлення створено більше 24 годин тому». Casbin — популярна cross-language бібліотека для ABAC.

ReBAC (Relationship-Based Access Control) — Google Zanzibar model. Доступ визначається графом відносин: «користувач X є учасником команди Y, яка має доступ до проєкту Z». OpenFGA — open source реалізація від Okta.

Як ми це робимо: кейс із впровадження 2FA

Проєкт — платіжний шлюз для маркетплейсу. Потрібно було захистити доступ до операцій виводу коштів. Ми спроєктували систему:

• Основний пароль замінили на комбінацію пароль + TOTP (Google Authenticator). Використали otplib (Node.js) для генерації та верифікації кодів.
• Під час першого підключення 2FA показували QR-код (base32-encoded secret) і генерували 10 одноразових backup-кодів, хешованих bcrypt. Відображали коди лише один раз.
• Secret для TOTP зберігали у зашифрованому вигляді в базі даних (AES-256-GCM, ключ у AWS KMS).
• На стороні фронтенду інтегрували @simplewebauthn/browser для passkeys — біометрична аутентифікація як альтернатива паролю. Публічний ключ зберігали на сервері, private key на пристрої користувача.
• Результат: час на логін зріс на 5 секунд, але кількість зламаних акаунтів упала до нуля за пів року роботи. Гарантія безпеки — на рівні OWASP ASVS Level 2.

Також варто зазначити, що TOTP значно надійніше за SMS-верифікацію через SIM-swapping, тому для фінансових даних ми рекомендуємо TOTP або апаратні ключі.

Типові вразливості, які ми знаходимо

• Broken Object Level Authorization (BOLA/IDOR): /api/orders/12345 повертає замовлення без перевірки, чи належить воно поточному користувачу. Найпоширеніша вразливість API за OWASP. Кожен запит до ресурсу — перевірка через $user->can('view', $order).
• Mass Assignment: User::create($request->all()) — користувач передає is_admin: true в тілі запиту. Laravel вирішує через $fillable / $guarded, але часто забувають.
• Небезпечний CORS: Access-Control-Allow-Origin: * на API з авторизацією по cookie — credentials не передаються з wildcard origin, але якщо хтось зробив Allow-Credentials: true + Allow-Origin: * — це діра.

Penetration testing обов’язковий для продуктів з фінансовими даними або персональними даними користувачів. Ми проводимо аудит коду й інфраструктури на етапі приймання.

Що входить у роботу

Ми передаємо замовнику:

• Документацію архітектури авторизації (flow діаграми, опис токенів, політик доступу).
• Репозиторій із вихідним кодом, покритий unit- та integration-тестами.
• Конфігурацію для CI/CD (GitHub Actions/ GitLab CI) із перевірками безпеки.
• Доступи до середовищ (staging, production) із правами адміністратора.
• Інструкцію з експлуатації та супроводу.
• Підтримку після впровадження — 2 тижні безкоштовних консультацій.

Терміни та вартість

Базова аутентифікація (email/password + OAuth + JWT/сесії): 1–3 тижні. RBAC з детальними політиками доступу: 2–4 тижні. 2FA (TOTP + SMS): 1–2 тижні. WebAuthn/Passkeys: 2–3 тижні. Повна система аутентифікації для SaaS з multi-tenancy: 4–8 тижнів.

Вартість розраховується індивідуально залежно від обсягу та складності. Замовте консультацію — оцінимо ваш проєкт безкоштовно. Отримайте гарантію безпеки вашої авторизації користувачів.