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 — это практики, которые делают безопасность по умолчанию, а эволюцию — быстрой и безболезненной для команд и партнеров.