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

Надежный контур 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/ре-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, строгая изоляция тенантов/регионов, аудит и телеметрия. Такой дизайн делает изменения безопасными, объяснимыми для регулятора и прозрачными для продукта — а масштабирование по рынкам и командам становится рутинной операцией, а не подвигом.