Autentifikatsiya va avtorizatsiya

AuthN/AuthZ ishonchli konturi - bu siz kim ekanligingiz (autentifikatsiya) va sizga nima ruxsat berilganligi (avtorizatsiya) haqidagi haqiqatning yagona nuqtasi. Ko’plab brendlar, mintaqalar, integratsiyalar va yuqori tartibga solish talablariga ega platformada ushbu kontur «xizmatlar bo’yicha if-lar tarqalishi» emas, balki modulli, kuzatiladigan va siyosatchilar tomonidan boshqariladigan bo’lishi kerak.

1) Bazaviy atamalar va rollar

Identifikatsiya (ID): shaxsni aniqlash (user, service, provider).
Autentifikatsiya (AuthN): shaxsning isboti (parol, MFA, sertifikat).
Avtorizatsiya (AuthZ): siyosat va kontekst asosida «mumkin/mumkin emas» qarorini qabul qilish.
PDP/PEP: Policy Decision Point (qaror qabul qiladi )/Policy Enforcement Point (qoʻllaydi).
IdP: identifikatsiya provayderi (OIDC).
Subject/Resource/Action/Context: kim/nima/nima/qanday sharoitda.

2) Konturning umumiy arxitekturasi

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

Prinsiplari: tokenlar va siyosatlar ishlab chiqarishni markazlashtirish, mahalliy qo’llash; «eng kam imtiyozlar» va aniq topshiriqlar.

3) Foydalanuvchilarning autentifikatsiyasi (OIDC/OAuth 2. 1)

• Authorization Code + PKCE (har doim SPA/Mobile uchun).
• SSO: b2b/operatorlar uchun tashqi IdP (SAML/OIDC) ni qoʻllab-quvvatlash.
• MFA: TOTP/WebAuthn/SMS (WebAuthn va TOTP tomonidan tavsiya etilgan; SMS — fallback).
• Risk-based Step-Up: sezgir harakatlarda (mablag’larni chiqarish, rekvizitlarni o’zgartirish) MFA/pe-Auth talab qilish.

• Refresh Token Rotation + qayta foydalanish detektoriga ega RT reyestri.
• Nonce/State + PKCE, brauzer oqimlari uchun qattiq 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) Autentifikatsiya servis-xizmati (mTLS, SPIFFE, JWT)

mTLS + SPIFFE/SPIRE xizmatlari o’rtasida barqaror workload identifikatorlari uchun.
HSM/KMS tomonidan imzolangan Service JWT qisqa muddatga (≤ 5 daqiqa); berish auditi.
Audience-scoped: JWT faqat muayyan xizmat/domen uchun mos keladi.
Ishonch zonalari: boshqa mintaqadan xizmatlar/tenant - alohida PKI va siyosat.

5) Avtorizatsiya modellari: RBAC, ABAC, ReBAC

RBAC (rollar → ruxsatnomalar): oddiy va shaffof (ma’muriy panellar, operatorlar uchun mos).
ABAC (subyekt/resurs/kontekst atributlari): "tenant =... AND region=… AND kyc_tier≥2».
ReBAC (munosabatlar): murakkab egalik uchun foydalidir («brend/jild/kampaniyaga kim egalik qiladi»).

Tavsiya: gibrid - bazaviy RBAC + kontekstli ABAC shartlari + nuqtaviy ReBAC munosabatlari.

6) Siyosat va ularning ijrosi (PDP/PEP)

Gateway va servislardagi PEP: kontekstni (JWT, mandatlar, IP/ASN, vaqt, mintaqa, KYC-daraja) chiqaradi, PDPga so’rovni shakllantiradi.

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

va’ALLOW/DENY’+ tushuntirishini qaytaradi.

PEPdagi yechimlar keshi (TTL 30-120 c) latentlikni kamaytiradi; «rollar/siyosatning o’zgarishi» voqealari bo’yicha nogironlik.

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) Tovarlar va ruxsatnomalar

• Manba:’wallet: read’,’wallet: transfer’,’bets: place’,’kyc: status. read`.
• Ma’murlar uchun izolyatsiya qilingan domenda’admin:’.
• Provayderlar uchun -’provider: report. read`, `provider:events. push`.

Eng kam imtiyozlar prinsipi: biz faqat kerakli tovarlarni tayinlaymiz; «eskalatsiya» (huquqlarning vaqtinchalik kengayishi) - tiket bo’yicha va TTL bilan.

8) Multi-tenant va mintaqalar (residency)

Tokenlarda’tenant’,’region’,’licence’mavjud; PDP resursga muvofiqligini tekshiradi.
Rollar/siyosatlar - per tenant (’role: brand _ eu/support’).
Imzo kalitlari va chaqirib olish ro’yxatlarini mintaqalar bo’yicha ajratish; kross-mintaqaviy so’rovlar - faqat ishonchli shlyuzlar orqali.

9) Sessiyalar va qurilmalarni boshqarish

Server-side session store for web (qurilmaga/brauzerga bogʻlash, identifikatorni almashtirish).
Idle/Absolute Timeout (masalan, 30 min/24 soat); sezgir harakatlar - re-Auth/MFA.
Aktiv qurilmalar listingi, «hammadan chiqish».
Anomaliyalar: bir vaqtning o’zida turli mintaqalardan kirish, tez-tez MFA muvaffaqiyatsizliklari - xavf signallari.

10) Delegatsiya va rozilik (consent)

On-behalf-of (OBO): xizmat foydalanuvchi nomidan ishlaydi (alohida’sub ’/’ act’bilan proksi-token).
Rozilik: sherikning ma’lumotlardan foydalanish uchun ochiq ekran, fikr-mulohazalar jurnali.
Vaqtinchalik access-mandates: N soat/kun huquqlari avtomatik ravishda tugaydi.

11) Kalitlar, imzolar va rotatsiya

JWKS s’kid’, avtomatik rotatsiya, shaxsiy kalitlarni KMS/HSMda saqlash.
Algoritmlar: JWT uchun ES256/EdDSA; TLS 1. 2+/mTLS.
Dual-key davri: ikkala’kid’ni mijozlarni yangilash tugaguniga qadar qabul qilish.
Tanqidiy hodisalar uchun RT va Token Introspection sharhlari.

12) Mijoz ilovalarining xavfsizligi

SPA: Authorization Code + PKCE, no `implicit`, строгий CORS/Content-Security-Policy.
Mobile: App Attestation/Device Check, RT himoyalangan ombor, rut/jailbreyk himoyasi.
Desktop: login uchun tizim brauzeri (no embedded web-views), PKCE.

13) SDKning qulay kontraktlari

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) Kuzatuv va 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`
• Kirish anomaliyalari (new device, geo-velocity), shubhali skuplar.

• `who/what/when/where/why`, `decision`, `policy_version`, `token_kid`, `client_id`.
• Komplayens uchun eksport (regulyator/vendor-audit).

15) Perimetr va mijozni himoya qilish

Gateway PEP: rate-limit, bot/signature checks, CSRF-himoya, qattiq CORS, HSTS.
Ichki trafik: mTLS + servis JWT + cheklangan tarmoqlar.
Vebxuklar/tashqi kolbeklar: tana imzolari (HMAC/JWS), vaqt oynalari, anti-replay.

16) Tipik xatolar

Uzoq umr koʻradigan access-tokenlar → oqish.
SPA ga OAuth implisit oqimi.
Kalitlar rotatsiyasi va Dual-Key davri yo’qligi.
Siyosat o’rniga zahardkoje rollar (qarorlarni tinglash/tushuntirish mumkin emas).
Tanantlar/mintaqalarni bitta’role’yoki’key’bilan aralashtirish.
Sezgir harakatlarda step-up MFA yoʻq.
Rollarni o’zgartirish bo’yicha nogironligi bo’lmagan AuthZ yechimlari keshi.

17) Pleybuklar (runbooks)

1. JWT imzo kalitini buzish

Darhol revoke’kid’, yangi JWKSni e’lon qilish, RT/sessiyalarni majburiy nogironlashtirish, audit hisoboti.

2. Ommaviy’invalid _ token ’

Soatlar/hayot vaqtini, JWKSning dolzarbligini, kesh muvaffaqiyatsizliklarini tekshirish.

3. Kirish anomaliyalari

Yuqori tavakkalchilik-skoringni yoqish, step-up talab qilish, foydalanuvchini xabardor qilish, to’lovlarni vaqtincha cheklash.

4. IdP muvaffaqiyatsiz tugadi

Sessiya keshiga/rol-apparatga oʻtish, yangi loginlarni cheklash, amaldagi sessiyalarni TTLgacha ushlab turish.

18) Sotishdan oldingi chek-varaq

• OIDC/OAuth 2. 1 ta PKCE, qisqa AT, RT rotatsiyasi, tanqidiy operatsiyalar uchun device binding.
• MFA (WebAuthn/TOTP) va step-up.
• Service-to-service: mTLS + SPIFFE, qisqa umr ko’radigan servis JWT.
• Markazlashtirilgan PDPda AuthZ (RBAC + ABAC/ReBAC) siyosati; gateway va servislarda PEP.
• Nogironligi bo’lgan qarorlar keshi; audit trail oʻzgarmas.
• Ko’p tenant/mintaqalar: kalitlarni/siyosatlarni/loglarni izolyatsiya qilish, litsenziyalarni hisobga olish.
• JWKS/KMS/HSM kalitlari, dual-key rotatsiyasi, monitoring’kid’.
• CSRF/CORS/HSTS/Rate-limit/bot-filtrlar perimetrda.
• Voqealar pleybuklari, run-tugmalar revoke/rotate/lockdown.
• Testlar to’plami: unit (policies), contract (SDK/flows), chaos (IdP, JWKS), e2e (step-up, OBO, revoke).

19) Konfiguratsiyaning mini-shablonlari

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

Xulosa

Autentifikatsiya va avtorizatsiya konturi - bu kutubxona emas, balki platforma qobiliyati: qisqa yashaydigan tokenlar va boshqariladigan kalitlar, markazlashtirilgan siyosatlar va ularni mahalliy qo’llash, ko’p faktor va step-up, tenant/hududlarni qat’iy izolyatsiya qilish, audit va telemetriya. Bunday dizayn oʻzgarishlarni tartibga soluvchi uchun xavfsiz, tushunarli va mahsulot uchun shaffof qiladi - bozor va jamoalar boʻyicha masshtablash esa jasorat emas, balki odatiy operatsiyaga aylanadi.