JWT: struktur və boşluqlar

1) JWT nədir və harada istifadə olunur

JWT - «Base64Url» (başlıq) formatında kompakt özünü təmin edən təsdiq konteyneri (claims). Base64Url(payload). Base64Url(signature)`.

• JWS (imzalanmış tokenlər - orijinallıq/bütövlük),
• JWE (şifrəli tokenlər - məxfilik),
• access/ID tokenləri və service-to-service autentifikasiyası kimi OIDC/OAuth2.

Üstünlüklər: muxtariyyət, caching, kiçik əlavə xərclər. Mənfi cəhətləri: səhv validasiya riski, mürəkkəb geri çağırma halları.

2) JWT strukturu

2. 1 Başlıq (header, JSON)

Minimum: alqoritm və açar identifikatoru.

json
{ "alg": "ES256", "kid": "jwt-2025-10", "typ": "JWT" }

'alg': imza/şifrələmə alqoritmi (RS256/ES256/PS256/HS256 və s.).
'kid': açar göstəricisi (JWKS-rotasiya üçün).
Əlavə açar mənbələri: 'jku', 'x5u' (bax boşluqlar § 6. 3).

2. 2 Faydalı yük (payload, JSON)

• `iss` (issuer), `aud` (audience), `sub` (subject)
• 'exp' (son vaxt), 'nbf' (əvvəl deyil), 'iat' (verilmiş)
• 'jti' (token identifikatoru, rəy üçün yararlıdır)
• domain-damğalar: 'scope/roles', 'tenant', 'kyc _ level' və s.

2. 3 İmza (signature)

JWS = `sign(base64url(header) + "." + base64url(payload), private_key)`

Yoxlama: tam uyğun ictimai açar və tam olaraq server gözlədiyi alqoritm.

3) Əsas yoxlama invariantları

1. Alqoritm 'header' məzmununa etibar edilmir, resurs-server konfiqurasiyası (allow-list) ilə müəyyən edilir. alg`.
2. 'iss' və 'aud' dəqiqliyini yoxlayın, 'exp/nbf' - kiçik bir 'clock _ skew' (± 30-60s).
3. Yalnız «kid» olmadan tokenləri rədd edin və rotasiya yoxdur; əks halda - 'kid' tələb edin.
4. Obyekt səviyyəsində avtorizasiya olmadan heç bir markaya etibar etməyin (BOLA-first).
5. Parsinq - kriptovalyuta yoxlamasından sonra; dekodlama əvvəl əsas ölçüsü yoxlama.

4) JWS vs JWE

JWS: imzalanmış, lakin oxumaq. Payload PII/sirləri yerləşdirməyin.
JWE: payload şifrələyir; inteqrasiya daha mürəkkəbdir, əsas model kritikdir.
Əksər API kifayət JWS + payload həssas məlumatlara qadağa.

5) Tokenin həyat dövrü

Access: qısa müddət (5-30 dəqiqə).
Refresh: daha uzun (7-30 gün), rotate-on-use (birdəfəlik), «qara siyahı» saxlamaq 'jti/sid'.
Revocation: TTL ilə 'jti' siyahıları, opaque-tokenlər üçün introspektsiya, hadisələrdə 'exp' ixtisarı.
Açar rotasiyası: JWKS üst üstə (köhnə + yeni), «Açar rotasiyası» məqaləsinə baxın.

6) Tez-tez zəifliklər və onları necə bağlamaq olar

6. 1 'alg = none '/alqoritmin dəyişdirilməsi

Mahiyyət: server 'alg' sahəsinə etibar edir və imzalanmamış tokeni qəbul edir.
Müdafiə: serverdə sərt alqoritmlər allow-list; 'none' və gözlənilməz dəyərləri rədd edin.

6. 2 RS256 → HS256 swap (simmetrizasiya)

Mahiyyət: təcavüzkar 'alg' HS256 əvəz edir və HMAC gizli kimi ictimai açardan istifadə edir.
Müdafiə: konfiqurasiya alqoritminə açar bağlamaq; bir 'kid' simmetrik/asimmetrik provayderləri qarışdırmayın.

6. 3 Enjeksiyon açarları ('kid/jku/x5u')

• 'jku' təcavüzkarın nəzarət etdiyi JWKS-ə işarə edir (açarını qoyacaq).
• 'x5u '/' x5c' xarici sertifikatlardan sui-istifadə.
• 'kid' enjeksiyon yolu/SQL ('../../privkey. pem "'və ya' '' OR 1 = 1 -- '').

• Silinmiş 'jku/x5u' görməməzliyə vurun və ya ciddi allow-list domenləri ilə süzün.
• 'kid' yalnız yerli kataloq (cədvəl/önbellək) açarı kimi istifadə olunur, heç bir fayl yolları/SQL konkatenasiya.
• JWKS etibarlı URL ilə göndərmək, qısa TTL, imza/pinning kanal.

6. 4 Zəif HS256 sirləri (brutfors)

Mahiyyət: HMAC-gizli qısa/sızma → imzanın dəyişdirilməsi.
Qorunma: Asimmetriya (RS/ES/PS) və ya 256 bit ≥ gizli uzunluqdan istifadə edin, sırlar yalnız KMS-də.

6. 5 itkin/qeyri-palid markalar

No 'aud '/' iss '/' exp' → token xaç xidməti uyğun və ya sonsuzdur.
Çox uzun 'exp' → güzəşt riski.
Müdafiə: 'exp' qısa, 'nbf '/' iat' markalarının tam dəstini tələb etmək, 'clock _ skew' ilə təsdiqləmək.

6. 6 Replay və token oğurluğu

Mahiyyət: tokenin tutulması/təkrarlanması (loqlarda sızma, XSS, TLS olmadan MitM).

• TLS везде, `Secure`+`HttpOnly` cookie, SameSite=Lax/Strict.
• Partnyorlar üçün DPoP/PoP (tokenin müştəri açarına bağlanması) və/və ya mTLS.
• Qısa 'exp', refresh-rotasiya, device-binding.

6. 7 XSS/saxlama vasitəsilə sızma

Mahiyyət: JWT-ni 'localStorage '/' sessionStorage' → JS-də saxlamaq.
Qorunma: access-tokenləri HttpOnly-cookie-də saxlayın (cookie-model mümkündürsə) + ciddi CSP/Trusted Types.
Cookie olmadan SPA üçün - yaddaşdakı tokeni təcrid etmək, minimum yaşamaq, XSS-dən qorumaq.

6. 8 CSRF

Mahiyyət: cookies seanslarında üçüncü tərəf saytından sorğular.
Qorunması: SameSite, anti-CSRF tokenləri (double submit), 'Origin/Referer' yoxlama, Fetch-Metadata filtrləri.

6. 9 Oversize/ölçüsü sui-istifadə

Mahiyyət: böyük payload/başlıqlar, parsing üçün DoS.
Qorunma: başlıqlar/bədən ölçüsü limitləri, early-reject 431/413, markaların fiks dəsti.

6. 10 'typ '/' cty'

Mahiyyət: «JWT» növlərinin qarışıqlığı ('typ:' JWT '), daxili JOSE obyektləri.
Mühafizə: təhlükəsizlik üçün 'typ/cty' görməməzlikdən gələrək, sabit alqoritmlərə və markaların sxeminə güvənmək.

7) Tokenlərin saxlanması və ötürülməsi

7. 1 Server API (machine-to-machine)

mTLS/HMAC, tercihen JWT üçün asimmetriya, kanallar - mesh vasitəsilə.
Açar saxlama - KMS/HSM, cədvəl üzrə rotasiya, üst-üstə düşən JWKS.

7. 2 Brauzer müştəriləri

HttpOnly Secure Cookie для access/refresh; qısa TTL; yeniləmə - yalnız HTTPS altında 'SameSite = None' ilə «silent refresh» vasitəsilə.
Ciddi CSP, Trusted Types, XSS qorumaq; SPA üçün - mümkünsə tokeni diskdə saxlamayın.

8) JWKS, rotasiya və geri çağırış

JWKS avtorizator tərəfindən dərc olunur; istehlakçılar 5-15 dəqiqə keşlər.
Rotasiya planı: yeni 'kid' əlavə → onlara imza başlamaq → N gün sonra JWKS → purge köhnə silmək.
Baxış: 'jti/sid' c TTL siyahıları; hadisə müvəqqəti qısaldılması 'exp' və fors-logout (əlil refresh).

9) Multi-tenant və məlumatların minimuma endirilməsi

Yalnız memarlıq lazım olduqda 'tenant '/' org' tokeninə daxil edin; əks halda 'sub' PDP atributları çəkmək.
Heç bir PII; → sızma və korelasiya riski daha azdır.

10) Praktik validasiya yoxlama siyahısı (resurs serveri)

• Parsim yalnız imzanı və əsas ölçü limitlərini yoxladıqdan sonra.
• 'alg' konfiqurasiya; gözlənilməz rədd.
• 'iss' ∧ 'aud' ∧ 'exp' ∧ 'nbf' ∧ 'iat' (c 'clock _ skew').
• Yerli kataloq/JWKS (qısa TTL) üzrə 'kid' yoxlayın.
• Xarici işarələri süzün/normallaşdırın ('jku/x5u' - yalnız allow-list).
• Markaların uzunluğunu/tərkibini məhdudlaşdırın (sxem).
• Resurs üçün obyekt icazəsini tətbiq edin (BOLA-first).
• Log 'kid', 'sub', 'aud', 'iss', 'jti', 'exp', 'tenant', 'trace _ id' (PII olmadan).
• İmza səhvlərinin, gecikmələrin, rotasiya auditinin metrikası.

11) Təhlükəsiz siyasət nümunələri (psevdo)

11. 1 Alqoritm gözləntilərinin konfiqurasiyası

yaml jwt:
expected_issuer: "https://auth. example. com"
expected_audience: ["wallet-service"]
allowed_algs: ["ES256"] # fix the jwks_url: "https ://auth. example. com/.well-known/jwks. json"
jwks_cache_ttl: 600s clock_skew: 60s required_claims: ["iss","aud","sub","exp","iat"]

11. 2 Uzaqdan 'jku/x5u' imtina

yaml reject_untrusted_key_sources: true allowed_jku_hosts: ["auth. example. com"] # if absolutely necessary

11. 3 Baxış siyahısı nümunəsi (Redis)

pseudo if redis. exists("revoke:jti:" + jti) then deny()
if now() > exp then deny()

12) Müşahidə və forensika

Метрики: `jwt_verify_fail_total{reason}`, `jwt_expired_total`, `jwks_refresh_total`, доля `kid`.
Log (strukturlaşdırılmış): 'iss/aud/sub/kid/jti/exp/tenant/trace _ id', uğursuzluq səbəbi.
Daşbordlar: «tezliklə bitir», validasiya səhvlərinin artması, bölgələrə/müştərilərə paylanması.
Alertlər: 'verify _ fail' (imza/alqoritm), JWKS səhvləri, vaxtı keçmiş tokenlərin payları.

13) Antipattern

Etibarlı 'alg' token; dəstək 'none'.
Uzunmüddətli access-tokenlər və refresh-rotasiya yoxdur.
HS256 olmadan ENV-də qısa sirr/sirr.
Hər hansı bir domendən 'jku/x5u' qəbul edin; dinamik allow-list olmadan JWKS yükləmək.
Payload JWS PII/sirləri qoyun.
XSS riskləri olduqda 'localStorage' tokenlərini saxlayın.
Validasiya səhvlərini boğun («yumşaq error» ilə 200 qaytarın).
UŞAQ yoxlamalarının olmaması və yalnız 'scope/role' etibar.

14) iGaming/Maliyyə Xüsusiyyətləri

Damğalar: 'kyc _ level', 'risk _ tier', 'tenant', sərt 'aud'.
Write əməliyyatları üçün qısa TTL (depozitlər/çıxışlar), kritik marşrutlar üçün PoP/DPoP və ya mTLS.
Tənzimləyici audit: dəyişməz giriş/uğursuzluq jurnalları, region sərhədləri daxilində qeydlərin saxlanması.
Partnyorların/PSP-lərin ayrı-ayrı açarları/' aud ', per-tenant açarları və ayrı-ayrı JWKS-ləri var.

15) Prod hazırlıq yoxlama siyahısı

• Sərt alqoritmlər siyahısı; 'none' qadağandır.
• 'iss/aud/exp/nbf/iat/jti' yoxlanılır; qısa 'exp'.
• JWKS üst-üstə, qısa TTL cache; 'kid' paylarının monitorinqi.
• Refresh — rotate-on-use; TTL ilə 'jti/sid' siyahıları; baxış playbook.
• Kritik marşrutlarda PoP/DPoP və ya mTLS.
• Brauzer üçün HttpOnly-cookies, CSP/Trusted Types vs XSS; CSRF qorunması.
• Payload PII olmadan; minimum markalar dəsti.
• Validasiya və uğursuzluqlar üzrə metriklər/loqlar; alertlər JWKS/verify_fail.
• Mənfi ssenarilərin testləri: RS → HS swap, 'kid' inyeksiyaları, 'jku' spoofing, oversize, clock-skew.

16) TL; DR

Alqoritmi və açarları server tərəfinə yazın, 'alg' tokeninə etibar etməyin, 'iss/aud/exp/nbf/iat/jti' tələb edin. Açarları üst-üstə düşən JWKS vasitəsilə çevirin, tokenləri qısa ömürlü, refresh isə birdəfəlik saxlayın. Tokenləri təhlükəsiz saxlayın (veb üçün HttpOnly cookie), markaları minimuma endirin, PII qoymayın. 'jku/x5u/kid' -vektorları bağlayın, zəif sirlərlə HS256 çəkinin, kritik yollara PoP/DPoP və ya mTLS əlavə edin və həmişə resurs səviyyəsi üçün BOLA testləri edin.