Autentifikasiya və avtorizasiya

AuthN/AuthZ etibarlı konturu sizin kim olduğunuz (autentifikasiya) və icazə verildiyi (avtorizasiya) haqqında həqiqətin vahid nöqtəsidir. Bir çox marka, bölgə, inteqrasiya və yüksək tənzimləmə tələbləri olan bir platformada bu konturun «xidmətlər üzrə if-oların səpilməsi» deyil, modul şəklində, siyasətçilər tərəfindən müşahidə və idarə edilməsi lazımdır.

1) Əsas şərtlər və rollar

Identifikasiya (ID): şəxsiyyətin müəyyən edilməsi (user, service, provider).
Autentification (AuthN): şəxsiyyət sübut (parol, MFA, sertifikat).
Avtorizasiya (AuthZ): siyasət və kontekstə əsaslanan «mümkün/mümkün deyil» qərarının qəbul edilməsi.
PDP/PEP: Policy Decision Point (həll edir )/Policy Enforcement Point (tətbiq edir).
IdP: identifikasiya provayderi (OIDC).
Subject/Resource/Action/Context: kim/nə/nə edir/hansı şərtlərlə.

2) Ümumi kontur arxitekturası

[ 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)

Prinsiplər: tokenlərin və siyasətlərin generasiyasının mərkəzləşdirilməsi, yerli tətbiqi; «minimum imtiyazlar» və açıq nümayəndəliklər.

3) Istifadəçilərin identifikasiyası (OIDC/OAuth 2. 1)

• Authorization Code + PKCE (həmişə SPA/Mobile üçün).
• SSO: b2b/operatorlar üçün xarici IdP (SAML/OIDC) dəstəyi.
• MFA: TOTP/WebAuthn/SMS (WebAuthn və TOTP tərəfindən tövsiyə olunur; SMS — fallback).
• Risk-based Step-Up: həssas hərəkətlərdə (pul çıxarılması, rekvizitlərin dəyişdirilməsi) MFA/pe-Auth tələb.

• Refresh Token Rotation + təkrar istifadə detektoru ilə RT reyestri.
• Nonce/State + PKCE, tarayıcı axınları üçün ciddi CORS/CSRF.
• Short-lived access tokens (5–15 мин) + silent refresh/RT.
• Device binding (DPoP/mtls-bound tokens) kritik əməliyyatlar üçün.

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) Autentifikasiya xidməti (mTLS, SPIFFE, JWT)

sabit workload identifikatorları üçün + SPIFFE/SPIRE xidmətləri arasında mTLS.
HSM/KMS tərəfindən imzalanmış qısa müddət (≤ 5 dəq) ilə JWT Service; emissiya auditi.
Audience-scoped: JWT yalnız xüsusi bir xidmət/domen üçün uyğundur.
Etimad zonaları: başqa bir bölgədən/tenantdan xidmətlər - ayrı-ayrı PKI və siyasətlər.

5) Avtorizasiya modelləri: RBAC, ABAC, ReBAC

RBAC (rolları → qətnamə): sadə və şəffaf (inzibati panellər, operatorlar üçün uyğun).
ABAC (subyekt/resurs/kontekstin atributları): "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (əlaqələr): mürəkkəb mülkiyyət üçün faydalıdır («kim marka/qovluq/kampaniya sahibidir»).

Tövsiyə: hibrid - əsas RBAC + kontekstli ABAC şərtləri + nöqtəli ReBAC münasibətləri.

6) Siyasət və onların icrası (PDP/PEP)

Gateway və xidmətlərdə PEP: konteksti çıxarır (JWT, mandatlar, IP/ASN, vaxt, region, KYC səviyyəsi), PDP-yə sorğu formalaşdırır.

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" }
}

və qaytarır 'ALLOW/DENY' + izahat.

PEP-də cache həlləri (TTL 30-120 c) gecikməni azaldır; «rolların/siyasətlərin dəyişdirilməsi» hadisələrinə görə əlillik.

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) Satınalmalar və icazələr

• Resurs: hərəkət - 'wallet: read', 'wallet: transfer', 'bets: place', 'kyc: status. read`.
• Adminlər üçün - 'admin:' təcrid olunmuş domendə.
• Provayderlər üçün - 'provider: report. read`, `provider:events. push`.

Minimum imtiyazlar prinsipi: yalnız lazımi alıcıları təyin edirik; «eskalasiya» (hüquqların müvəqqəti genişləndirilməsi) - bilet və TTL ilə.

8) Multi-tenant və regionlar (residency)

Tokenlər 'tenant', 'region', 'licence'; PDP resurs uyğunluğunu yoxlayır.
Rollar/siyasətlər - per tenant ('role: brand _ eu/support') ad boşluqları.
İmza açarları və geri çağırış siyahılarının bölgələrə bölünməsi; cross-regional sorğular - yalnız etibarlı şlüzlər vasitəsilə.

9) Sessiyaların və cihazların idarə edilməsi

Server-side session store for web (cihaz/brauzer bağlantısı, identifikatorun rotasiyası).
Idle/Absolute Timeout (məsələn, 30 dəq/24 saat); həssas hərəkətlər - re-Auth/MFA.
Aktiv cihazların listinqi, «hamıdan çıxış».
Anomaliyalar: müxtəlif bölgələrdən eyni vaxtda girişlər, tez-tez MFA uğursuzluqları - risk siqnalları.

10) Nümayəndəlik və razılıq (consent)

On-behalf-of (OBO): xidmət istifadəçi adından fəaliyyət göstərir (ayrı 'sub '/' act' ilə proxy-token).
Razılıq: partnyorun məlumatlara daxil olması üçün açıq ekran, rəy ilə razılıq jurnalı.
Müvəqqəti access-mandates: N saat/gün hüquqları avtomatik olaraq sona çatır.

11) Açarlar, imzalar və rotasiya

JWKS ilə 'kid', avtomatik rotasiya, KMS/HSM-də xüsusi açarların saxlanması.
Alqoritmlər: JWT üçün ES256/EdDSA; TLS 1. 2+/mTLS.
Dual-key dövrü: Hər iki 'kid' müştərilərin yenilənməsi başa çatana qədər qəbul.
Kritik hadisələr üçün RT və Token Introspection baxış.

12) Müştəri tətbiqi təhlükəsizliyi

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobile: App Attestation/Device Check, RT qorunan saxlama, root/jailbreak qorunması.
Desktop: giriş üçün sistem brauzeri (no embedded web-views), PKCE.

13) Rahat SDK müqavilələri

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) Müşahidə və audit

• `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`
• Giriş anomaliyaları (new device, geo-velocity), şübhəli skuplar.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• Komplayens üçün ixrac (tənzimləyici/satıcı-audit).

15) Perimetr və müştəri qorunması

Gateway PEP: rate-limit, bot/signature checks, CSRF qorunması, ciddi CORS, HSTS.
Daxili trafik: mTLS + xidmət JWT + məhdud şəbəkələr.
Vebhuk/xarici kolbeklər: bədən imzaları (HMAC/JWS), vaxt pəncərələri, anti-replay.

16) Tipik səhvlər

Uzunmüddətli access-tokenlər → sızmalar.
SPA-da OAuth implisit axını.
Açarların rotasiyası və Dual-Key dövrü yoxdur.
Siyasətin əvəzinə cazibədar rollar (qərarları dinləmək/izah etmək mümkün deyil).
Bir 'role' və ya 'key' -də tenant/bölgələrin qarışması.
Həssas hərəkətlərdə step-up MFA yoxdur.
AuthZ həllərinin rol dəyişikliyi ilə bağlı əlilliyi olmayan cache.

17) Playbooks (runbooks)

1. JWT imza açarının güzəşti

Dərhal revoke 'kid', yeni JWKS-in nəşri, RT/sessiyaların məcburi əlilliyi, audit hesabatı.

2. Kütləvi 'invalid _ token'

Saat/həyat vaxtı, JWKS aktuallığını, cache nasazlıqlarını yoxlayın.

3. Giriş anomaliyaları

Artırılmış risk hesabını daxil edin, step-up tələb edin, istifadəçiyə məlumat verin, ödənişləri müvəqqəti olaraq məhdudlaşdırın.

4. IdP uğursuzluğu

Cache seansları/rol aparatı keçid, yeni girişləri məhdudlaşdırmaq, TTL üçün mövcud seansları saxlamaq.

18) Satış öncəsi yoxlama siyahısı

• OIDC/OAuth 2. 1 PKCE, qısa AT, RT rotasiya, kritik əməliyyatlar üçün cihaz bağlama ilə.
• MFA (WebAuthn/TOTP) və step-up/rekvizitlərin dəyişdirilməsi/rolun eskalasiyası.
• Service-to-service: mTLS + SPIFFE, qısa ömürlü JWT xidmətləri.
• Mərkəzləşdirilmiş PDP-də AuthZ (RBAC + ABAC/ReBAC) siyasətləri; PEP gateway və xidmətlərdə.
• Əlilliyi olan qərarların cache; audit trail dəyişməz.
• Multi-tenant/regionlar: açar/siyasət/log izolyasiyası, lisenziyaların uçotu.
• JWKS/KMS/HSM açarları, dual-key rotasiya, 'kid' monitorinqi.
• CSRF/CORS/HSTS/Rate-limit/bot-filtrlər perimetrdə.
• Playbook hadisələr, run-düymələri revoke/rotate/lockdown.
• Test dəsti: unit (policies), contract (SDK/flows), chaos (IdP, JWKS), e2e (step-up, OBO, revoke).

19) Mini konfiqurasiya şablonları

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."]

Nəticə

Autentifikasiya və avtorizasiya konturu kitabxana deyil, platforma qabiliyyətidir: qısa ömürlü tokenlər və idarəolunan açarlar, mərkəzləşdirilmiş siyasətlər və onların lokal tətbiqi, çox faktor və step-up, tenant/bölgələrin ciddi izolyasiyası, audit və telemetriya. Bu dizayn dəyişiklikləri təhlükəsiz, tənzimləyici üçün izah edilə bilən və məhsul üçün şəffaf edir - və bazarlar və komandalar üzrə miqyas rutin bir əməliyyata çevrilir, şücaət deyil.