OAuth2/OpenID Connect в ядрі

OIDC поверх OAuth2 - стандартний спосіб довести «хто користувач/клієнт» і видати короткоживучий доступ до API. У ядрі платформи він стає центральною здатністю: єдиний вхід для клієнтів, операторів і сервісів; мінімальні привілеї; вимірний ризик; дотримання регіональних та ліцензійних правил.

1) Цілі та принципи

Розділення «deploy vs enable»: викочуємо код окремо, включаємо доступ прапорами/політиками.
Короткоживучі токени + безпечне оновлення: знижуємо збитки при витоках.
Мульти-тенант/регіон: всі артефакти мітяться'tenant/region/licence'.
Політики поверх токенів: рішення робить PDP (RBAC/ABAC), PEP на gateway/сервісах.
Захист каналів: TLS1. 2 +, по можливості mTLS/DPoP, строгий CORS/CSRF.
Спостережуваність і аудит: видимість по потоку, по клієнту, по регіону.

2) Потоки і коли їх застосовувати

Authorization Code + PKCE (SPA/Mobile/Web) - дефолт для користувацьких логінів.
Device Authorization (консолі/TV/CLI) - коли немає браузера.
Client Credentials (machine-to-machine) - сервісні інтеграції без користувача.
Token Exchange (RFC 8693, OBO) - сервіс діє від імені користувача.
CIBA/Back-channel (за бажанням) - пуш-аутентифікація без редиректу.

• PAR (Pushed Authorization Requests) - параметри авторизації передаються по захищеному серверному каналу.
• JAR (JWT Secured Authorization) - параметри запиту підписані/зашифровані.
• JARM - захищена відповідь авторизації (JWT), стійка до підміни.
• RAR (Rich Authorization Requests) - багаті запити прав на доступ (деталізовані дозволи).

3) Токени і клейми

• ID Token (OIDC) - хто увійшов (показувати тільки клієнту/фронту).
• Access Token (AT) - право на дію (коротке життя).
• Refresh Token (RT) - оновлює AT; зберігається тільки в довіреному середовищі.

• AT: 5-15 хв (web/mobile), 2-5 хв (service-to-service).
• RT: 7–30 дней (web/mobile) с rotation + reuse detection.
• ID: ≤ 5 хв.

json
{
"iss":"https://auth. core",
"sub":"user_42",
"aud":["wallet","catalog"],
"exp":1730388600,"iat":1730388000,
"tenant":"brand_eu","region":"EE","licence":"EE-A1",
"scp":["wallet:read","bets:place"],     // scopes
"sid ": "sess _ abcd, ""amr": [" pwd,"" webauthn"] ,//login methods
"act":{"sub":"svc. catalog" }//if OBO
}

Підписання: ES256/EdDSA, публічні ключі - в JWKS з'kid'і ротацією.

4) Контур сесій і logout

Server-side session для web (cookie `SameSite=Lax/Strict`, `HttpOnly`, `Secure`).
Back-Channel Logout + Front-Channel Logout (OIDC) - синхронне завершення всіх клієнтів.
Step-Up MFA: при чутливих діях - повторна перевірка («acr» підвищується).
Revocation & Introspection: негайне відключення RT/AT по інциденту.

5) Безпека клієнтів

Web/SPAs: Authorization Code + PKCE, ніякого implicit; строгий CORS/Content-Security-Policy.
Mobile: системний браузер (AppAuth), перевірка цілісності (App Attestation/DeviceCheck), захищене сховище RT.
Desktop/CLI/TV: Device Flow; зберігайте RT в OS-секрет-сховищах.
DPoP або mTLS-bound tokens для прив'язки AT до пристрою/з'єднання.

6) Сервіс-к-сервісу

mTLS + короткі Service JWT (aud-scoped), видає STS з KMS/HSM.
Ідентичності workload'ів: SPIFFE/SPIRE.
Політика «від вузького до широкого»: конкретні audience і scopes замість ".

7) Scope-реєстр та згода (consent)

Іменування: 'ресурс:дія'-'wallet:read`, `wallet:transfer`, `bets:place`, `kyc:status. read`.

Конфігуруйте видимість і чутливість скоупів.
Consent screen збирається з RAR/Scopes; зберігайте історію згоди і дозволяйте відгук.

json
{
"type":"wallet. transfer",
"actions":["create"],
"locations":["https://api. core/wallet"],
"datatypes":["payment"],
"resources":[{"wallet_id":"w_123","currency":"EUR","amount_max":1000}]
}

8) Інтеграція з авторизацією (PDP/PEP)

PEP на API Gateway валідує AT/DPoP/mTLS, збагачує контекст (IP/ASN/region/tenant), робить запит до PDP.
PDP (OPA/cedar) застосовує RBAC/ABAC/ReBAC-політики і повертає'ALLOW/DENY'з поясненням і TTL.
Кеш рішень у PEP (TTL 30-120 с) з інвалідацією по подіям (зміна ролей/правил).

9) Мульти-тенант і регіони

Всі токени і сесії маркуються'tenant/region/licence'; PDP валідує відповідність ресурсу.
Роздільні JWKS/ключі та списки відкликання по регіонах; крос-регіон - через довірені шлюзи.
Обмеження резидентності даних: інтроспекція/ревокація виконуються в регіоні походження.

10) Протоколні посилення

PAR + JAR + JARM - захищають параметри та відповіді авторизації.
Nonce/State/PKCE - для всіх публічних клієнтів.
Pushed Device Authorization (при високому ризику).
JWT Access Tokens з мінімальними клеймами + opaque варіант для зовнішніх інтеграцій через інтроспекцію.
FAPI-подібні практики: строгі алгоритми підпису, вимоги до TLS/redirect_uri/PKCE.

11) Помилки і політика повернення

json
{ "error":"invalid_grant", "error_description":"refresh token reused", "error_code":"RT_REUSE" }

Критичні коди: `invalid_request`, `invalid_client`, `invalid_grant`, `invalid_scope`, `unauthorized_client`, `access_denied`, `temporarily_unavailable`.
Rate-limit для чутливих ендпоінтів ('/token', '/introspect', '/revoke'), експоненціальний backoff.

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

• `auth_code_success_rate`, `pkce_missing_rate`, `mfa_challenge/fail_rate`,
• `token_issuance_p95_ms`, `jwks_skew_ms`, `invalid_token_rate`, `rt_reuse_detected`,
• за API: `authz_p95_ms`, `deny_rate{reason}`, `dpop_mismatch_rate`, `mtls_fail_rate`.

Логи/трейси: `client_id`, `grant_type`, `kid`, `acr/amr`, `tenant/region`, `decision`, `policy_version`, `aud`, `scp`, `sid`, `trace_id`.
Аудит (незмінний): видачі токенів, ескалації прав, відкликання згоди, ротації ключів.

13) Управління ключами та ротація

Підпис JWT: KMS/HSM, публікація JWKS з'kid'.
Dual-key період: IdP підписує новим, перевіряючі приймають старий + новий до перемикання.
Регулярна ротація і екстрений revoke; моніторинг споживання'kid'.

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

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

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

2. Масові'invalid _ token '/зростання 401

Перевірити розсинхрон годинника, що минув AT, зламаний JWKS-кеш; тимчасово збільшити толеранс'clock _ skew'.

3. Повторне використання RT

Заблокувати сесію ('sid'), повідомити користувача, зажадати step-up для нового входу, розслідування.

4. Падіння IdP

Увімкнути режим «read-only авторизація»: тримати діючі AT до TTL, обмежити нові логіни, скейлити кеш інтроспекції.

5. Атака на '/token '

Підсилити rate-limit/бот-фільтри, включити mTLS/DPoP для чутливих клієнтів, винести «холодні» RT в окремий сегмент.

15) Тестування

Contract: OIDC discovery, JWKS, OpenID provider config.
Security: PKCE/nonce/state обов'язкові; negative-набори (підміни'redirect _ uri', reuse RT).
Interoperability: клієнти (web/mobile/CLI), різні часові пояси/локалі.
Chaos: відмова PAR/JARM, затримки JWKS, rotated'kid'« на льоту ».
E2E: step-up MFA, OBO (token exchange), logout (front/back-channel), revoke/rotate.

16) Приклади конфігурацій

yaml issuer: https://auth. core jwks:
rotation_days: 30 alg: ES256 tokens:
access_ttl: 10m refresh_ttl: 14d id_ttl: 5m policies:
require_pkce: true require_par: true require_jarm: true dpop_enabled: true mfa_step_up:
actions: ["wallet:transfer","payout:initiate"]
tenancy:
include_claims: ["tenant","region","licence"]
jwks_per_region: true

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

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

• Включені PKCE/nonce/state; PAR/JAR/JARM активні.
• AT/RT/ID TTL задані; RT rotation + reuse detection включені.
• DPoP або mTLS-binding для чутливих клієнтів/операцій.
• JWKS c `kid`; автоматична ротація та моніторинг споживання ключів.
• Consent/RAR і реєстр скоупів; step-up MFA для чутливих дій.
• PDP/PEP інтегровані, кеш рішень з інвалідацією.
• Токени містять'tenant/region/licence'; дотримується residency.
• Спостережуваність: метрики, логи, трасування; альберти на'invalid _ token','rt _ reuse','jwks _ skew'.
• Плейбуки на revoke/rotate/lockdown; кнопка аварійного логауту.
• Набір E2E/chaos/interop тестів пройдено на стендах.

Висновок

Вбудувавши OAuth2/OIDC як платформну здатність, ви отримуєте передбачувані потоки авторизації, керовані токени, єдині політики доступу і вимірний ризик. Короткі AT, захищені RT, ротація ключів, PAR/JARM/DPoP, згода і step-up - це практики, які роблять безпеку за замовчуванням, а еволюцію - швидкою і безболісною для команд і партнерів.