GH GambleHub

API va tokenlar xavfsizligi

Qisqacha xulosa

API xavfsizligi - bu autentifikatsiya, avtorizatsiya, kriptografik himoya, suiiste’molchilikka qarshi va kuzatuvchanlik mexanizmlari majmui bo’lib, so’rov kutilayotgan sub’ekt kutilayotgan resursga kutilayotgan kontekstda bajarilishini ta’minlaydi. Asosiy artefakt - chaqirish huquqini tasdiqlovchi token (yoki so’rov imzosi). Yaxshi arxitektura qisqa umr ko’radigan tokenlar, aniq skoplar, minimal imtiyozlar, takrorlashlardan himoya qilish, rate limiting va operatsion tartib-taomillarga (rotatsiyalar, audit, hodisalar) tayanadi.

API autentifikatsiya modellari: qachon va nima tanlash kerak

API-kalit (statik sir)

B2B integratsiyalari va past riskli stsenariylar uchun oson. Kontekstga ega emas, xizmat tomonida saqlashni talab qiladi.
Faqat IP/ASN allow-list, belgilangan kvotalar, qisqa TTL va rotatsiyalar bilan foydalaning.

OAuth 2. 1 / OIDC

Foydalanuvchi va sherik integratsiyalari uchun standart: access token (qisqa yashovchi) + refresh token (rotatsiya) + skoplar.
Public-mijozlar - PKCE bilan; confidential-mijozlar - mijozlar siri/mTLS bilan.

Client Credentials (m2m)

Mashina → mashina: access token xizmatlar uchun qat’iy belgilangan skuplar va audience, ko’pincha refresh (qayta olish).

mTLS (oʻzaro TLS)

Identifikatsiyani kanalga bogʻlaydi. Yuqori tavakkalchilik yoki to’lov integratsiyalari uchun ideal (TLS ustidagi PoP).
OAuth bilan birlashtirilishi mumkin (tokenlar faqat mTLS mijozlari bo’yicha).

Soʻrov imzolari (HMAC/EdDSA)

Transportdan mustaqil bo’lgan PoP kerak bo’lganda: imzo sarlavhasi, timestamp va nonce. Vebxuk va oflayn tekshirish uchun qulay.

Tokenlarning formatlari va turlari

JWT (JWS, imzolangan)

O’zini o’zi ta’minlaydigan, lokal tekshiriladi; ’iss’,’sub’,’aud’,’exp’,’iat’,’jti’,’scope’bo’lishi shart.
Xavf - chaqirib olish qiyinroq: qisqa TTL (5-15 daqiqa) + hodisalarda chaqirib olingan’jti’ro’yxatidan foydalaning.

JWE (shifrlangan JWT)

Agar payload sezgir boʻlsa kerak (PII). Qiymati murakkablik va qo’shimcha xarajatlardan yuqori.

Reference tokens

Shaffof bo’lmagan identifikatorlar Authorization Server’da introspection orqali tekshiriladi.

PoP/DPoP

Tokenni mijoz kalitiga yoki TLS sessiyasiga bogʻlash, oʻgʻirlangan tokenning qiymatini pasaytiradi.

Token tarkibi: minimal yetarli

Tavsiya etilgan tamg’alar (JWT):
  • ’iss’ (issuer),’sub’(subject),’aud’(maqsadli tizim/resurs),’exp’(muddat),’iat’,’nbf’(ixtiyoriy),’jti’.
  • ’scope ’/’ permissions’ (minimal zarur),’tenant’(ko’p tenantlar uchun),’device _ compliant ’/’ amr’(autentifikatsiya usuli),’ip ’/’ asn’(agar siyosatga qo’llanilsa).
Qoidalar:
  • Qisqa TTL access uchun (5-15 daqiqa), refresh - 12-48 soat (aylanma rotatsiya bilan).
  • Auditoriya (’aud’) - qat’iy aniq resurs, aks holda «qayta ishlatiladigan» token.
  • Shoplar - harakat va obʼekt (masalan,’payments: withdraw. read`).
  • O’lchami - sarlavhalar va proksi uchun 2-4 KB ≤; aks holda geytveylar bilan bog’liq muammolar bo’lishi mumkin.

Avtorizatsiya va siyosat

RBAC + ABAC: rol + kontekst (tashkilot, geo, xavf, qurilmaning holati).
PEP/PDP: tokenni tekshirish va ilovadan oldin API/proxy (Envoy/OPA) shlyuzida qaror qabul qilish.
Deklarativ qoidalar: Git’da saqlash, CI’da policy-tests’dan oʻtish.

Rego misoli (soddalashtirilgan):
rego package policy. withdraw

default allow = false

allow {
input. token. aud == "wallet-api"
input. token. scope[_] == "payments:withdraw. create"
input. device. compliant == true input. risk. score < 70
}

So’rovlar imzosi (HMAC) va anti-replay

Kerak bo’lganda: vebxuklar, OAuthsiz integratsiyalar, tanqidiy operatsiyalarni ikki marta tekshirish.

Sarlavhalar sxemasi (misol):

X-Client-Id: <id>
X-Timestamp: 2025-11-05T13:20:10Z
X-Nonce: 4d1f...a2
X-Signature: base64(HMAC_SHA256(secret, method + "\n" + path + "\n" + sha256(body) + "\n" + timestamp + "\n" + nonce))
Qoidalar:
  • Sof vaqt soʻrovini rad etish> 300 ±
  • Nonce 5-15 daqiqa saqlash va takrorlashni qabul qilmaslik (replay-kesh).
  • Soʻrovning kanonlashtirilgan koʻrinishini (usul, yoʻl, query, tana xeshi) imzolash.

Idempotentlik va tranzaksion himoya

Idempotency-Key hisobdan chiqarish/toʻlash/yaratish operatsiyalari uchun: bir xil kalit → bir xil effekt.
Kalitning umr ko’rish muddati - biznes taymautning ≥ vaqti (odatda 24-72 soat).
Mantiq server tomonida: Soʻrov parametrlarini kalit uchun avval oʻrnatilgan bilan solishtirish.

Brauzer va mobil mijozlar

PKCE majburiy (public-mijozlar).
Brauzerdagi refresh-tokendan qochish; agar kerak bo’lsa - ROTATION + takrorlashga javob berish (replay-detekt).
Saqlash: session storage> local storage; yaxshiroq - tokenlar uchun backend for frontend (BFF) javob beradi.
SameSite, Secure, HttpOnly для cookie; CORS - aniq allow-lists, sarlavhalar va usullar; preflight-keshlash xavfsiz.

m2m va yuqori xavfli integratsiyalar

mTLS + OAuth2 Client Credentials i’aud’.
Geytveyda IP/ASN allow-list.
Tanqidiy operatsiyalar uchun TLS ustidagi PoP/DPoP yoki HMAC imzolari.
Tashkilot/mijoz/kalit uchun kvotalar va rate limits.

Rotatsiyalar, qaytarishlar va hodisalarga munosabat bildirish

Imzo sirlari va kalitlarini almashtirish (JWKS): jadval boʻyicha + hodisada majburan.
Dual-key rollout: yangi asosiy juftlikni oldindan e’lon qiling (kid2), uning tokenlarini imzolang, eski (kid1) ni TTL tugaguniga qadar tasdiqlash uchun saqlang.
Refresh-rotation: har bir almashinuv refresh → yangi token, eskisi darhol bekor qilinadi; takrorlash - murosaga kelish signali.
Revocation: JWT uchun - qisqa muddatga chaqirib olingan’jti’ro’yxati; reference tokenlar uchun - AS da darhol blokirovka qilish.
Break-glass stsenariylari: minimal huquqlar va qattiq TTL bilan vaqtinchalik statik kreddlarni jurnalga yozib oling.

Rate limiting, bot-himoya va ortiqcha chiqishdan himoya

Uch qatlamli limitlar: per-key/per-IP/per-tashkilot.
Burst + sustained: token-bak/siljish oynasi.
Murakkab tekshiruvlar: device fingerprint, xulq-atvor signallari, geo/ASN anomaliyalari, CAPTCHA faqat UI uchun.
Lockout/slowdown imzoni/NMASni takrorlashda va autentifikatsiya qilish muvaffaqiyatsiz boʻlganda.

Logografiya, metrika va SLO

Minimal loglar toʻplami:’request _ id’,’client _ id’,’sub’,’aud’,’scope’,’decision’,’reason’,’jti’,’ip’,’asn’,’latency’,’quota _ state’.

Metriklar:
  • Tokenlar validatsiyasining muvaffaqiyati (%), p95 verifikatsiya vaqti.
  • Replay-ogʻishlar chastotasi, Idempotency-Key dublikatlari.
  • PoP/DPoP/mTLS bilan soʻrovlar ulushi.
  • ’aud/scope’, tugagan’exp’, vaqt siljishi (NTP) xatolari.
SLO (misollar):
  • Auth/AS ≥ 99. 95 %/oy; p95 introspection ≤ 50 мс.
  • Nol tokenlar bilan TTL <60 c proda (muhofaza metrikasi).
  • 0 dan kam. Kuniga 1%’aud/scope’xatosi (integratsiya sifati).

Konfiguratsiya namunalari

Envoy: JWT va audience’ni tekshirish

yaml http_filters:
- name: envoy. filters. http. jwt_authn typed_config:
providers:
as:
issuer: https://auth. example. com/
audiences: ["wallet-api"]
remote_jwks:
http_uri:
uri: https://auth. example. com/.well-known/jwks. json cluster: jwks_cluster cache_duration: 600s rules:
- match: { prefix: "/v1/withdraw" }
requires:
provider_and_audiences:
provider_name: as audiences: ["wallet-api"]

NGINX: mTLS к backend

nginx proxy_ssl_server_name on;
proxy_ssl_name wallet. internal;
proxy_ssl_certificate   /etc/nginx/mtls/client. crt;
proxy_ssl_certificate_key /etc/nginx/mtls/client. key;
proxy_ssl_trusted_certificate /etc/nginx/mtls/ca. crt;
proxy_ssl_verify on;
proxy_ssl_verify_depth 2;

Imzo sarlavhasi namunasi (vebxuki)


X-Signature: t=1730803210,n=ac12...,s=base64(HMAC_SHA256(secret, "POST\n/webhook\nsha256(body)\n1730803210\nac12..."))

Agar’t’300 c dan katta boʻlsa,’n’allaqachon uchrashgan boʻlsa yoki’s’ishlamasa, server rad etadi.

Ma’lumotlarni himoya qilish va maxfiylik

Tamg’alarni (ayniqsa PII) va umr ko’rishni minimallashtiring.
Uchinchi tomon integratsiyalari uchun sezgir markalarni (JWE) shifrlang.
Mask/DLP log’larda: PAN/PII bilan tanalarni, tokenlarni faqat’kid ’/bayroqlarni logga tushirmaslik, sirning o’zi emas.

Tipik xatolar

Uzun oqimli access-tokenlar va «abadiy» refresh.
’aud ’/’ scope’ → mavjud emas.
Vebxuklarning imzosi’timestamp ’/’ nonce’.
JWTni faqat gatveyda (PEP) emas, balki dasturda tekshirish.
Rotatsiyalar va dual-key rollout yo’qligi.
KORS «» va ruxsat etilgan xavfsiz usullar sarlavhalar nazoratisiz.
BFFsiz’localStorage’da tokenlarni saqlash.

Joriy etish yo’l xaritasi

1. API inventarizatsiyasi va tasnifi (ommaviy/sheriklik/ichki, sezgirlik).
2. AuthN modelini tanlash: foydalanuvchilar uchun OAuth2/OIDC, mTLS + Client Credentials/HMAC uchun m2m.
3. Tokenlar: qisqa TTL, qattiq’aud’, skoplar, tanqidiy operatsiyalar uchun DPoP/PoP.
4. Geytveydagi PEP: JWT, imzo va rate limitsni ilovaga validatsiya qilish.
5. Anti-replay va idempotentlik: timestamp/nonce/Idempotency-Key.
6. Rotatsiya va JWKS: dual-key, avtomatlashtirish va alerting.
7. Kuzatish darajasi: metriklar/SLO, kirish jurnallari, UEBA-signallar.
8. Mashqlar: imzo kalitini qaytarib olish, refresh oqishi, kvotalarni ortiqcha yuklash.

iGaming/fintech uchun xususiyatlar

To’lovlar/to’lovlar: faqat mTLS + PoP/HMAC, qat’iy sotib olishlar (’withdraw. create’), idempotency majburiydir.
Hamkorlar (PSP/kontent provayderlari): per-partner kalitlari/sertifikatlari, IP/ASN allow-list, alohida kvotalar va dashbordlar.
GDPR/PCI DSS: markalarni minimallashtirish, tashqi tokenlarda PIIni taqiqlash, sezgir resurslardan foydalanishni loglash, muntazam access review.
Anti-abuse: xulq-atvor limitlari, geo-nazorat, API darajasida bonus-abyuzdan himoya qilish.

FAQ

JWT yoki reference token?
JWT - unumdorlik va avtonomlik; reference - markazlashtirilgan chaqirib olish va hodisa-reaktsiyaning soddaligi. Ko’pincha gibrid: tashqi - JWT, ichki - reference.

JWE kerakmi?
Faqat payloadda PII/sirlar mavjud boʻlsa. Aks holda - minimal markali JWS.

API kalitlarida yashash mumkinmi?
Ha, lekin faqat qisqa TTL, qat’iy kvotalar, IP-allow-list va so’rovlar imzosi bilan. Foydalanuvchilar uchun - afzalroq OAuth/OIDC.

DPoP/PoP talab qilinadimi?
Har doim ham emas. Lekin high-risk operatsiyalari (to’lovlar, xulosalar) uchun - juda maqbul.

Jami

APIning ishonchli xavfsizligi qisqa yashaydigan tokenlar, aniq xaridlar va auditoriya, himoyalangan kanallar (TLS/mTLS), so’rovlar imzosi va qat’iy anti-replay himoyasiga asoslanadi. Avtomatlashtirilgan rotatsiyalar, dual-key rollout va geytveylarda siyosiy nazoratni qo’shing - va sizning APIingiz yuqori samaradorlik va boshqaruvchanlikni saqlab qolgan holda sizib chiqish, takrorlash va suiiste’mollarga chidamli bo’ladi.

Contact

Biz bilan bog‘laning

Har qanday savol yoki yordam bo‘yicha bizga murojaat qiling.Doimo yordam berishga tayyormiz.

Telegram
@Gamble_GC
Integratsiyani boshlash

Email — majburiy. Telegram yoki WhatsApp — ixtiyoriy.

Ismingiz ixtiyoriy
Email ixtiyoriy
Mavzu ixtiyoriy
Xabar ixtiyoriy
Telegram ixtiyoriy
@
Agar Telegram qoldirilgan bo‘lsa — javob Email bilan birga o‘sha yerga ham yuboriladi.
WhatsApp ixtiyoriy
Format: mamlakat kodi va raqam (masalan, +998XXXXXXXX).

Yuborish orqali ma'lumotlaringiz qayta ishlanishiga rozilik bildirasiz.