Автентифікація та авторизація

Надійний контур AuthN/AuthZ - це єдина точка істини про те, хто ви (автентифікація) і що вам дозволено (авторизація). У платформі з безліччю брендів, регіонів, інтеграцій і високими регуляторними вимогами цей контур повинен бути модульним, спостережуваним і керованим політиками, а не «розсипом if-ів по сервісах».

1) Базові терміни і ролі

Ідентифікація (ID): встановлення особи (user, service, provider).
Автентифікація (AuthN): доказ особи (пароль, MFA, сертифікат).
Авторизація (AuthZ): прийняття рішення «можна/не можна» на основі політик і контексту.
PDP/PEP: Policy Decision Point (приймає рішення )/Policy Enforcement Point (застосовує).
IdP: провайдер ідентифікації (OIDC).
Subject / Resource / Action / Context: хто/до чого/що робить/за яких умов.

2) Загальна архітектура контуру

[ IdP (OIDC) ]
│ OIDC/OAuth 2. 1 (PKCE, JAR/JARM)

[ Token Service / JWKS / KMS ]
│klyuchi (rotate)
│ JWT/Access/Refresh, mTLS

[API Gateway (PEP)] Solution/Policy ──kesh
│ authN/CSRF/CORS/rate-limit

[ Microservices (PEP)]──PDP (OPA/cedar) ──Policy Store (GitOps)
│audit/metriki

[ Data/Providers ]── service-to-service (mTLS+JWT/Spiffe)

Принципи: централізація генерації токенів і політик, локальне застосування; «мінімальні привілеї» і явні делегування.

3) Автентифікація користувачів (OIDC/OAuth 2. 1)

• Authorization Code + PKCE (завжди для SPA/Mobile).
• SSO: підтримка зовнішніх IdP (SAML/OIDC) для b2b/операторів.
• MFA: TOTP/WebAuthn/SMS (рекомендовані WebAuthn і TOTP; SMS — fallback).
• Risk-based Step-Up: при чутливих діях (виведення коштів, зміна реквізитів) вимагати MFA/pe-Auth.

• Refresh Token Rotation + реєстр RT з детектом повторного використання.
• Nonce/State + PKCE, строгий CORS/CSRF для браузерних потоків.
• Short-lived access tokens (5–15 мин) + silent refresh/RT.
• Device binding (DPoP/mtls-bound tokens) для критичних операцій.

json
{
"iss": "https://auth. example. com",
"sub": "user_9f12",
"aud": ["wallet","catalog"],
"exp": 1730385600,
"iat": 1730384700,
"tenant": "brand_eu",
"region": "EE",
"amr": ["pwd, ""webauthn"] ,//authentication methods
"scp": ["wallet:read","bets:place","kyc:status. read"],
"sid": "sess_a1b2c3",      // session id
"acr": "urn: mfa: strong "//warranty level
}

4) Автентифікація сервіс-сервіс (mTLS, SPIFFE, JWT)

mTLS між сервісами + SPIFFE/SPIRE для стійких ідентифікаторів workload'ів.
Service JWT c коротким терміном (≤5 хв), підписаний HSM/KMS; аудит видачі.
Audience-scoped: JWT годиться тільки для конкретного сервісу/домену.
Зони довіри: сервіси з іншого регіону/тенанта - окремі PKI і політики.

5) Моделі авторизації: RBAC, ABAC, ReBAC

RBAC (ролі → дозволу): просто і прозоро (підходить для адмін-панелей, операторів).
ABAC (атрибути суб'єкта/ресурсу/контексту): гнучко для правил "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (відносини): корисно для складних володінь («хто володіє брендом/папкою/кампанією»).

Рекомендація: гібрид - базова RBAC + контекстні ABAC-умови + точкові ReBAC-відносини.

6) Політики та їх виконання (PDP/PEP)

PEP на Gateway і в сервісах: витягує контекст (JWT, мандати, IP/ASN, час, регіон, KYC-рівень), формує запит до PDP.

json
{
"subject": { "sub":"user_9f12", "roles":["support"], "kyc":2, "tenant":"brand_eu" },
"action": "bets. place",
"resource": { "game_id":"g_42", "provider":"pr_x" },
"context": { "region":"EE", "ip_asn":"AS12345", "time":"2025-10-31T12:34:56Z" }
}

і повертає'ALLOW/DENY'+ пояснення.

Кеш рішень у PEP (TTL 30-120 c) знижує латентність; інвалідація за подіями «зміна ролей/політик».

rego package bets

default allow = false

allow {
input. action == "bets. place"
input. subject. kyc >= 2 input. subject. tenant == input. context. tenant not blocked_region within_limits
}

blocked_region { input. context. region == "NL" }
within_limits { input. context. bet_amount <= data. limits. max_bet[input. subject. tenant] }

7) Скоупи та дозволи

• Ресурс:дія -'wallet:read`, `wallet:transfer`, `bets:place`, `kyc:status. read`.
• Для адмінів -'admin:'в ізольованому домені.
• Для провайдерів -'provider:report. read`, `provider:events. push`.

Принцип мінімальних привілеїв: призначаємо тільки потрібні скоупи; «ескалації» (тимчасові розширення прав) - за тікетом і з TTL.

8) Мульти-тенант і регіони (residency)

Токени містять «tenant», «region», «licence»; PDP перевіряє відповідність ресурсу.
Ролі/політики - простору імен per tenant ('role:brand_eu/support`).
Розділення ключів підпису і списків відкликання по регіонах; крос-регіональні запити - тільки через довірені шлюзи.

9) Управління сесіями та пристроями

Server-side session store для web (прив'язка до пристрою/браузеру, ротація ідентифікатора).
Idle/Absolute Timeout (напр., 30 хв/24 год); чутливі дії - re-Auth/MFA.
Лістинг активних пристроїв, «вихід з усіх».
Аномалії: одночасні входи з різних регіонів, часті провали MFA - сигнали ризику.

10) Делегування та згода (consent)

On-behalf-of (OBO): сервіс діє від імені користувача (проксі-токен з окремим'sub '/' act').
Згода: явний екран для доступу партнера до даних, журнал згоди з відкликанням.
Тимчасові access-mandates: права на N годин/днів, автоматично закінчуються.

11) Ключі, підписи та ротація

JWKS з'kid', автоматична ротація, зберігання приватних ключів в KMS/HSM.
Алгоритми: ES256/EdDSA для JWT; TLS 1. 2+/mTLS.
Dual-key період: прийом обох'kid'до завершення оновлення клієнтів.
Відгук RT і Token Introspection для критичних інцидентів.

12) Безпека клієнтських додатків

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobile: App Attestation/Device Check, захищене сховище RT, захист від рут/джейлбрейк.
Desktop: системний браузер для логіна (no embedded web-views), PKCE.

13) Зручні контракти SDK

http
POST /authz/evaluate
Authorization: Bearer <access_jwt>
Body: { "action":"bets. place", "resource":{"game_id":"g_42"}, "context":{"bet_amount":5. 0} }
→ 200 { "decision":"ALLOW", "ttlMs":60000, "explain":"kyc>=2, limit ok" }

http
POST /oauth/token grant_type=urn:ietf:params:oauth:grant-type:token-exchange subject_token=<user_jwt>&actor_token=<service_jwt>&audience=wallet

14) Спостережуваність і аудит

• `authn_success_rate`/`mfa_challenge_rate`/`mfa_fail_rate`
• `authz_p95_ms`, `authz_denied_rate{reason}`
• `invalid_token_rate`, `jwks_skew_ms`, `rt_reuse_detected`
• Аномалії входів (new device, geo-velocity), підозрілі скоупи.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• Експорт для комплаєнсу (регулятор/вендор-аудит).

15) Захист периметра і клієнта

Gateway PEP: rate-limit, bot/signature checks, CSRF-захист, строгий CORS, HSTS.
Внутрішній трафік: mTLS + сервісні JWT + обмежені мережі.
Вебхуки/зовнішні коллбеки: підписи тіла (HMAC/JWS), вікна часу, анти-реплей.

16) Типові помилки

Довгоживучі access-токени → витоку.
Імпліцитний потік OAuth в SPA.
Відсутність ротації ключів і Dual-Key періоду.
Захардкожені ролі замість політик (неможливо аудіювати/пояснювати рішення).
Змішування тенантів/регіонів в одному'role'або'key'.
Немає step-up MFA на чутливих діях.
Кеш рішень AuthZ без інвалідації за змінами ролей.

17) Плейбуки (runbooks)

1. Компрометація ключа підпису JWT

Негайний revoke'kid', публікація нового JWKS, примусова інвалідація RT/сесій, звіт аудиту.

2. Масові'invalid _ token '

Перевірити розсинхрон годин/час життя, актуальність JWKS, збої кешу.

3. Аномалії входів

Включити підвищений ризик-скоринг, вимагати step-up, повідомити користувача, тимчасово обмежити виплати.

4. Збій IdP

Переключитися на кеш сесій/роль-апарат, обмежити нові логіни, утримувати діючі сесії до TTL.

18) Чек-лист перед продом

• OIDC/OAuth 2. 1 з PKCE, короткі AT, ротація RT, device binding для критичних операцій.
• MFA (WebAuthn/TOTP) і step-up для висновків/зміни реквізитів/роль-ескалацій.
• Service-to-service: mTLS + SPIFFE, короткоживучі сервісні JWT.
• Політики AuthZ (RBAC + ABAC/ReBAC) в централізованому PDP; PEP на gateway і в сервісах.
• Кеш рішень з інвалідацією; audit trail незмінний.
• Мульти-тенант/регіони: ізоляція ключів/політик/логів, облік ліцензій.
• JWKS/ключі в KMS/HSM, dual-key ротація, моніторинг'kid'.
• CSRF/CORS/HSTS/Rate-limit/бот-фільтри на периметрі.
• Плейбуки інцидентів, run-кнопки revoke/rotate/lockdown.
• Набір тестів: unit (policies), contract (SDK/flows), chaos (IdP, JWKS), e2e (step-up, OBO, revoke).

19) Міні-шаблони конфігурацій

yaml scopes:
wallet: read: {desc: "Reading balance"}
wallet: transfer: {desc: "Transfer of funds," sensitive: true, step_up: true}
bets: place: {desc: "Bet"}
kyc:status. read: {desc: "KYC status"}
roles:
support:
allow: [wallet:read, kyc:status. read]
finance:
allow: [wallet:read, wallet:transfer]
player:
allow: [bets:place]

yaml deny:
- when: { region: ["NL","BE"] }
actions: ["bets."]

Висновок

Контур автентифікації та авторизації - це не бібліотека, а платформна здатність: короткоживучі токени і керовані ключі, централізовані політики і локальне їх застосування, багатофактор і step-up, сувора ізоляція тенантів/регіонів, аудит і телеметрія. Такий дизайн робить зміни безпечними, зрозумілими для регулятора і прозорими для продукту - а масштабування по ринках і командах стає рутинною операцією, а не подвигом.